After the team has picked the requirements from the Project Backlog, during the Sprint Planning Meeting, the team normally drafts a Sprint Backlog, the team starts working on the requirements and through a Daily Stand Up during the Sprint and updates the Sprint Backlog. Once the sprint is complete, the time comes to demonstrate working functionality. For this, the team and product owner gather together for Sprint Review. A Sprint Review is a meeting where the team demonstrates working software corresponding to project backlog items they have completed in a given sprint. There are some simple rules for a Sprint Review:

• The meeting is kept very informal. The team should not have to spend time preparing for the same beyond getting working software ready.
• Powerpoints, presentations, speeches and lectures are not allowed.
• You can only demonstrate working software.
• The preparation [working environment, arranging room] is done by the Agile Coach or Scrum Master.
• The meeting generally lasts about 1 hour per week of work [but this obviously can change depending on number of team members working for the project].
• The whole team, product owner or customers and stakeholders participate in the Sprint Review Meeting.

Of the above focus on “working software” is very important. This keeps the teams focus on delivering working software and adopting processes which aid delivery of the same. Thats another reason why any aids like PowerPoint slides or lectures are not allowed. The team would typically demonstrate each code it has written either through GUI, mock objects or through API calls. Actual working software allows product owner or customer to get first hand experience of the working features and based on the same provide feedback to the team. The feedback to the team is typically of these components:

• Whether they completed enough requirements
• Whether they completed requirements quite early
• Whether they understood the requirements and translated them to working features well enough

All three help the team and product owner plan for the next sprint better. At the end of sprint review meeting, Agile Coach or Scrum Master would announce the date for next Sprint Review and confirm the date for next Sprint Planning session. This sets the tone for the next sprint. After the Sprint Review Meeting, the team moves towards the Sprint Retrospectives.

The Sprint Review also works as a feedback channel for the Product Owner in some ways. The Product Owner invites stakeholders and customers who give her the actual feedback which she can factor into her requirements for future. She can then edit or delete any requirement or add new ones. In addition, they help the Product Owner identify the correct priority for requirements and minimize the biggest risk of all - developing the wrong thing as well as the second biggest risk - developing the wrong thing, the wrong way. Hence, Sprint Review is basically a “feedback, inspect and adaptation” channel in an Agile Development Framework.

Popularity: 19%

Posted on February 28th, 2008 by admin
Filed under: Assessment, Collaboration, Introduction, Practices | No Comments »

In our posts on Project Backlog, What is a Sprint, Sprint Backlog Introduction, Spirit of Sprint Backlog and Updating the Sprint Backlog, we emphasized a key Scrum [and Agile] ceremony : Sprint Planning Meeting. Agile is an iterative and incremental framework. In Scrum, each iteration is usually called a sprint. This is more than just another name. It signifies that each sprint is not only an iteration but also an increment. A sprint is started with a sprint planning meeting.

Lets say we are in the first sprint. Assuming that there is already a project backlog, picks up “x” number of top priority requirements [remember, the project backlog is in the order of priority]. The “x” requirements are selected through an educated guess that they can complete these requirements. A good project backlog would not only be prioritized but also estimated. The team totals the “relative estimation points” for all these requirements and that becomes the “velocity” of the team for first sprint. After discussing with the product owner, the team finalizes the requirements it would take up in the first sprint and the backlog roughly appears like this:

As you can see the team has committed to 20 points of work. As this is the first sprint, the team might need to take on more work [finish all requirements too soon] or need to bump off some requirements [if they find they committed to too much work]. The team ask as many questions as possible [acceptance test cases/ test data/ UI designs etc] as they can to the product owner for each requirement and give a final committment before moving to Part II of the sprint planning session. In this session they take each requirement and break them into tasks and the team member voluneteer, discuss and self assign these tasks. A typical sprint backlog after this could look like this:

You can read more about Sprint Backlog in our previous posts:

• The Spirit of Sprint Backlog
• Updating the Sprint Backlog
• Sprint Backlog an Introduction

Hence, a sprint planning meeting is basically communication channel with product owner on what requirements to complete in a given sprint and the team doing some ground work on getting going with the sprint. There are however, some rules of engagement, that the team and product owner need to adhere to:

• The product owner would not coerce the team into committing to more requirements than they feel comfortable with. After a few sprints, the teams velocity would be evident. However, the product owner is free to discuss his feedback on whether the team has optimal velocity during sprint review.
• The sprint planning meeting is not the only meeting where product owner needs to be available. The team can request product owner to be available during the sprint at regular interval [if they can sit with the team, nothing like it] to answer any questions or provide feedback or for JAD sessions.
• The sprint planning meeting should be around 2 hours for each week of sprint - 1 hour for discussion on requirements discussion and 1 hour for task breakdown. This is not a ground rule but anything longer is an overhead that you can do without. Also, the above ratio generally has worked for many teams and output quality - effort input ratio generally decreases for longer meetings. However, the teams might need longer meetings in initial sprints or critical sprints and shorter ones during later sprints.
• Finally, in Scrum at least and preferably in other flavors of Agile as well, once the team committs to the story - there would be no change: no change in development team, no change in the requirements and no swapping. However, clarifications can be provided. If the team and product owner is divided on whether it is a change or clarification, it is a change. This is done to maintain team focus on what they commit and get a rhythm going after a few sprints.

After the first sprint is over, and the team goes for second sprint planning meeting, they know how many requirements they can commit to. This information becomes even more concrete in later sprints. The project backlog could look like this after sprint 2 sprint planning meeting:

Sprint planning meeting provides the team and product owner a powerful collaboration tool to plan ahead, plan iteratively and plan with knowledge of immediate past and visibility of immediate future - in essence, allows you to take decisions when they should be - not too early or too late. Combining sprint planning with effective project backlog writing practices [see YAGNI], business value can be delivered sooner in a project.

Popularity: 18%

Posted on February 15th, 2008 by admin
Filed under: Business Alignment, Collaboration, Introduction, Practices | 1 Comment »