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: 15%

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

Sprint backlog is a Scrum Artifact that many Agile teams find useful. A sprint backlog [as mentioned in Ken Schwabers Book] helps the team in following ways:

• It allows them to see where they are and how much work is pending in a sprint
• Provides them focus for working during any given day
• Helps the team self organize by making them coordinate activities daily
  • In short, sprint backlog should help in implementation of Agile methods.

It is important to note why certain practices regarding “updating a sprint backlog” are designed the way are. In this post, we review the “why” of sprint backlog and practices regarding updating the sprint backlog:

• Sprint backlog is incremental and iterative. The team tries and divides as many requirements as they can into tasks. However, even the most experienced teams would discover tasks/ dependencies on system [arrange installation of particular IDE for instance] during the sprint. The difference between effort required to divide the entire project backlog into a sprint backlog that is “100% complete” and “reasonably complete” during a sprint planning meeting is immense. Hence, the teams could decide [especially for sprints longer than 2 weeks] to just break part of project backlog into tasks and start the sprint. They can add the tasks as they discover them. It is important to note here that teams committ to the requirements from a project backlog [estimated using relative estimation techniques] and hence, sprint backlog tracking is not “directly related” to how many requirements they can complete in a given sprint.
• A sprint backlog is a “team artifact” and they are not obliged to share it with anyone else. This is primarily because a sprint backlog is generally work in progress and can give only context based visibility. If the management or customers so desire, the team can keep a sprint wise project backlog of requirements and update the same when a requirement is completed. This is also important because Agile teams engage customers and management from requirements and features perspective. They would provide visibility from “this feature is done” perspective and not “this task in this feature is done, while feature is still work in progress”. The latter is not meaningful information as either the requirement is completed or not. In case management or customers wish to know how long it is to complete a requirement, they can ask the question during the sprint review meeting. The teams can decide to share the sprint backlog with the management or customers, probably after explaining how it works.
• Sprint backlog promotes teams “self organization”. One of the main rules of doing work is to plan effectively, revisit/ revise the plans and make effective decisions. Discussion of who would take what task and self volunteering for the same help the team collaborate and engage each other. This promotes self organization, as does the ability to take on tasks being done by someone else [if your task is completed or you find an important task is lagging behind]. In addition, every single team member updates the sprint backlog and its not a responsibility of one member alone. All the above are designed to have members talk to each other regularly, depend on each other and be one unit.
• Sprint backlog is “collective”. There is no such thing as “all tasks of A are done” and “two tasks of B are not done”. The team fails or succeeds as a team and not as an individual. Hence, the incentives are to be a team rather than lone rangers. This is again in keeping with the central Agile philosophy.
• Sprint backlog is “look ahead” at “work remaining” artifact. The team always focuses on “work remaining” as that is the thing they need to plan, organize and manage. Its no good knowing we have done “all this” till we know “this is what we still need to do”, as completing that would get the team to “done”.

As long as the teams maintain the spirit of sprint backlog as highlighted above, it would provide them a powerful tool [along with some others] to self organize, inspect and adapt during a sprint.

Popularity: 12%

Posted on February 14th, 2008 by admin
Filed under: Introduction, Values | 1 Comment »