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 »

In our last post we provided a brief introduction to Sprint Backlog, we discussed, how at the end of the sprint planning meeting, the team comes up with a reasonable estimate and breakdown of effort involved in converting the requirements to completed functionality. The detail of effort needed is usually called “task breakdown” and can be equated to “work breakdown structure” as mandated by “defined process control”. Often, this would be captured in a document format and at the end of sprint planning meeting, this looks like this:

After devising this backlog, the team gets down to work. However, the team visits the backlog once a day [typically after the daily stand up]. Basically, the team would update the backlog in these ways:

• They will update the hours remaining for each of the tasks. This is a subtle shift from traditional methods. The team is not recording “how many hours they spent on a given task” but “how many hours are left”. This is important because measuring how much you have come to makes sense in a defined journey [going from Los Angeles to San Francisco for instance] but not in software where you can only “estimate” the journey. Also, at all stages you can only manage whats coming ahead rather than whats past. However, some teams would track hours spent for tasks. This can be for purposes like estimation information for future or timesheets. However, like all things in Agile, it is left for the team to decide if they want to measure the time spent or not.
• The team can add/ edit/ delete tasks to the sprint backlog. There can be tasks that are discovered, as they work on requirements during the sprint. The team can take a task and break it into two or three or more tasks. The team can find that a given task is not needed [for instance UI secondary review or training for any technology] and hence, delete these tasks or keep the time remaining for these tasks as zero, from the day they discover, they don’t really need these tasks. This is especially true for tasks which can be completed in many ways [you can organize training for two people or get two new people on board for instance]. For each task deleted/ added/ edited - the team would discuss the reasons why the same had to be done during sprint review, especially if they are not able to complete the sprint target [complete all given requirements to working features].
• The team can re-assign a task to another team member either before the task has been started to be worked on or while it is being worked on. The “Responsible for” person column then has two names rather than one name.

After about 3 days of working, our backlog, after 3 days of regular updating, could appear like this:

Looking at above, lets understand sprint backlog a bit more:

• It appears that there are some tasks went fine - the team took them on and completed them [most of the tasks in white belong to this category]. However, on a closer inspection of the backlog, you don’t really know. You don’t know if the task was completed fine in the time the team originally estimated or whether team did it in less. This is because at the end of sprint, the first question you want to know is whether the task [and requirement] is completed or not. If all requirements are being faithfully developed into functionality, consistently and the team performance is improving every sprint, details of time spent/ exceeded seem trivial.
• Similarly, lets review the tasks highlighted in blue. We know at end of day 3 - the time remaining for the tasks is as much as we estimated. However, we do not know if the team has been working on these tasks at all or working hard enough but getting stuck after 8 hours of work. Interestingly, the task in yellow “Integration Testing” has more work left after 03 days. This can be due to rework, stringent or new quality checks or poor coding. Such details and patterns are easily observed using a “time remaining approach” and the team can discuss the same during sprint review meeting and possibly come up with root causes for why this is happening. Once, the root cause is identified, the team can devise a solution to overcome that.
• The task in green [last task] was discovered on third day and added to the backlog that particular day, while load testing of Member Sign In was assigned to two people.

After 05 days of updating, and before the sprint review, the sprint backlog could look something like below [this is ideal and hopefully the teams would get there after 3-4 sprints]. Any task not completed means corresponding story is also not completed.

In our next post, we will review the philosophy behind “time remaining approach” and “why is sprint backlog designed the way it is”.

Popularity: 16%

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