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

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

Product or project backlog is perhaps the single most important artifact in an Agile project. Here is a quick FAQ style introduction to product or a project backlog:

Question: What is a Product or Project Backlog?

Answer: A product or a project backlog is a prioritized list of requirements with a rough size and complexity estimate of each requirement. Hence, the backlog has 3 components: requirements, priority, rough size and complexity estimate.

Question: Who provides the requirements in Product or Project Backlog?

Answer: It is typically the role of a product owner or a customer to provide the requirements. However, sometimes analysts from the development team can work with product owner or customer to define the requirements. The idea is for the product owner or customer to work with the team to discuss the requirements during the sprint planning meeting.

Question: How are the requirements written?

Answer: There is no standard way to write the requirements. One team can simply write “users sign in” and another could write “users should be able to sign in with their email address and password”.

Question: Is additional information captured in the requirements?

Answer: Yes and no. It depends on project to project and requirement to requirement. Something like Forgot Password might not need further information but something like User Registration might have various notes on each field like date of birth (should be 13 or more) and password (strength).

Question: Do we require “acceptance tests” for the requirements?

Answer: Yes, highly recommended. However, having acceptance tests for all requirements would be too time consuming. Also, the team and product owner or customer should discuss the acceptance tests for each requirement in detail during the sprint planning meeting. It is useful to remember that Agile is collaborative and both the customer or product owner and team should discuss and agree on “definition of done” before the start of a sprint.

Question: Do we need details on everything for each requirement on the backlog?

Answer: This is not really required, although nothing stops you from going this route. However, the closer the requirements are placed to the current sprint, the better they should be defined.

Question: Do we need to estimate each requirement in the backlog?

Answer: Yes, it is recommended that each requirement be estimated. The requirements far from the current sprint can only be coarse grained and hence roughly estimated. However, this gives product owner or customer a rough idea of the project size and number of sprints required to complete a project. The final number of sprints could be more or less, but at each stage the visibility of progress would be self evident.

Question: How is the estimate done - in days or in hours?

Answer: You could use either, although relative estimation would work better. The team and product owner get together at sprint planning meeting. They pick up the simplest requirement from the list and arbitrarily assign a number to the same [say 1 or 1 requirement point or better still 1 coffee cup]. All other requirements are estimated in similar units [requirement points or coffee cups]. At the end you total up the points. At first the team could take a guess at the amount of points it could complete in a sprint. After a few sprints, they would have visibility of how many points they should ideally take. This estimation technique works well to give you rough idea of work that can be picked up. Its not supposed to be used for precise calculations or a point in horizon rather just aim for a region in horizon.

Question: How do we estimate - based on size or complexity?

Answer: The short answer to that is both! Entering 1000 records in database might not be complex, but time consuming and on the other hand investigate SOA performance issues in reports in a clustered environment may be complex and hence, difficult to even give a precise estimate on. And in some cases, you might want to factor in both. Hence, you estimate both from difficulty level as well as effort required.

Question: How is the backlog prioritized?

Answer: It is the responsibility of product owner or customer to prioritize the backlog. The team can provide assistance in the same though. The backlog is prioritized by factoring in risk factor of not doing the requirement right now and opportunity by delaying the requirement decision later. In simpler terms, risk factor, dependencies and business value would help the team decide the priority.

Question: Does the backlog provide any tracking?

Answer: Yes, you can make a simple tracking of completed/ pending items. You can also track number of requirement points completed in a sprint and based on average requirement points completed in a sprint and total requirement points pending, you can get an idea of the projected completion date. The average requirement points completed in a sprint is also called velocity.

Question: Is there a low level tracking involved?

Answer: Yes, you can divide each requirement into tasks. Each task can be estimated in number of hours it would take to complete. This is typically done only for a given sprint and is called a sprint backlog and is maintained separately from product or project backlog.

Question: Is the product or project backlog only made once - at the start of a project?

Answer: No! There are only two rules. First,the product or project backlog should be revised and continuously updated based on emergent scenarios and situation. Second, the backlog for the sprint currently in progress can’t be changed. The backlog for upcoming sprints can be changed almost completely. In a fixed price scenario, this might mean you need to swap new functionality with existing functionality.

Popularity: 65%

Posted on January 15th, 2008 by admin
Filed under: Business Alignment, Collaboration, Introduction, Practices | 2 Comments »