How To Implement Scrum in 10 Easy Steps - Step #4: Sprint Planning (Tasks)
by Kelly Waters
Once you’ve completed Step #3 and clarified the requirements for all the Product Backlog items targeted for your Sprint, the next step is to plan the Sprint in detail…
Sprint Planning Workshop (Part 2)
The first part of the Sprint Planning Workshop (in the last step of this series) was focused on clarifying the requirements for the selected Product Backlog. The second part of the Sprint Planning Workshop is focused on breaking the requirements into tasks and estimating the hours required to complete them.
Although Part 2 of the workshop can follow straight on from the first part, it is sometimes helpful for there to be a short gap between the two meetings; maybe 1 day. This allows time to clarify any outstanding questions arising from part 1 of the workshop before proceeding with the next step.
Make sure the meeting is attended by all team members. Include all roles. Business Analysts if you have them. Testers if you have them. ALL Developers on the Scrum team for the product.
The Product Owner and any customer, user or business representatives need not attend this part (part 2) of the Sprint Planning workshop, as it’s likely to be more technical in nature and is more about the team working out how the selected backlog items will be delivered.
However, they should be welcome to attend if they wish, which may help their understanding of what’s involved to deliver the features, and may help if any further clarification is required as the tasks are discussed and estimated.
Set the Sprint Budget
First of all, calculate the team’s Sprint Budget. This is the available number of hours the team has to work on the Sprint.
Start by multiplying the available hours in the Sprint Duration by the number of full-time people in the Sprint. For people who are working part-time in the Sprint, include the number of hours they can commit to.
Then, make any reasonable deductions for time that team members will not be able to spend working on the Sprint. Deduct holidays, any known meetings, any time likely to be spent working on other projects, etc. Based on past experience, deduct a reasonable amount of time for support, if appropriate.
Make sure all these calculations are transparent and visible to all.
Break Requirements into Tasks
Go through each Product Backlog item selected for the Sprint. Break the requirements into tasks.
Tasks may include the traditional steps in a development lifecycle (although limited to the feature in question, not the entire product). For instance: Design, Development, Unit Testing, System Testing, UAT (User Acceptance Testing), Documentation, etc.
Remember, agile software development methods do not exclude these steps. Agile methods just advocate doing the steps feature-by-feature, just in time, instead of in big phases.
Each of these tasks, especially development, may be broken down further. Maybe to a component level detailing each of the individual elements of the software architecture that will be required to deliver the feature of the product.
Include all tasks necessary to make the Product Backlog item 100% complete – i.e. potentially shippable – within the Sprint. Agree as a team on your definition of done, so everyone is aware what will have to be completed and included in the estimates.
State tasks as deliverables, if at all possible. Deliverables are more measurable than tasks. Instead of describing what you’re going to do, describe what you’re going to deliver.
Estimate Tasks in Hours
Keep tasks small. Estimate all tasks in hours. Estimate each task as a team.
Ask everyone what they think, in order to identify missed tasks, or to identify simpler solutions.
Ideally task estimates should be no more than 1 day. If an estimate is much larger than this, the requirements should be broken down further so the tasks are smaller. Although this can be difficult, it will get easier with practice.
Ideally task estimates should be no more than 1 day. If an estimate is much larger than this, the requirements should be broken down further so the tasks are smaller. Although this can be difficult, it will get easier with practice.
Keeping tasks small enough to estimate at less than 1 day has some specific benefits.
Firstly, breaking tasks down into very small chunks means they are easier to estimate. The accuracy of your estimating will be improved as a result. Secondly, tasks less than 1 day are more measurable in the daily Scrum (stand-up meeting). 1 day tasks are either done or they are not.
Firstly, breaking tasks down into very small chunks means they are easier to estimate. The accuracy of your estimating will be improved as a result. Secondly, tasks less than 1 day are more measurable in the daily Scrum (stand-up meeting). 1 day tasks are either done or they are not.
Commit to the Sprint Backlog
Add up all the task estimates for the selected Product Backlog.
If they are significantly over the team’s Sprint Budget, reduce the number of Product Backlog items selected for the Sprint. Remember the Product Backlog was in priority order, so if possible it should be the lower item(s) on the backlog that are removed from the Sprint.
The remaining list of estimated Tasks – those tasks needed to complete the selected Product Backlog within the Sprint - is your Sprint Backlog.
The team should commit to delivering the Sprint Backlog.
Identify Stretch Tasks
Sometimes teams under-commit or over-estimate. Stranger things have happened! :-)
In my experience this is quite common when teams are new to Scrum. I think it’s because they are unfamiliar with the process and potentially out of their comfort zone initially. They may not have had much experience of estimating in the past. And they may not have been asked to commit to their own delivery before. This can sometimes result in an over-cautious approach to the estimates.
Always include some additional scope in your Sprint Backlog, over and above what you think can be achieved. This is important in order to have something ready if the team delivers early, as the Sprint should ideally remain a fixed length.
Clearly identify these items as Stretch Tasks. The Product Owner should never expect Stretch Tasks to be reached. No-one should ever be beaten up if Stretch Tasks are never reached. And if you do manage to complete any Stretch Tasks, this should be cause for celebration!
Clearly identify these items as Stretch Tasks. The Product Owner should never expect Stretch Tasks to be reached. No-one should ever be beaten up if Stretch Tasks are never reached. And if you do manage to complete any Stretch Tasks, this should be cause for celebration!
Next…
So now you’ve got your backlog in order, estimated your backlog, clarified your requirements, and planned your sprint. Now you’re ready for Step #5 – Create a collaborative workspace…
See also:
How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...
- Step #10: Review, reflect, repeat...
'Implementing Scrum' PowerPoint Presentation
10 Key Principles of Agile Software Development
12 October 2007 07:00
I prefer estimating sprint tasks in *ideal* engineering hours. It explicitly leaves work like e-mail checking or going to unnecessary meetings out of the estimation - simplifies the estimations and in the end of the sprint might show how much time actually goes to these "extra" tasks.
9 January 2008 11:57
Hi,
Under "Breaking Requirements into Tasks" you write:
"Include all tasks necessary to make the Product Backlog item 100% complete – i.e. potentially shippable – within the Sprint."
Do you really mean that the list of tasks, i.e. the sprint backlog, should include all tasks to make the PRODUCT BACKLOG 100% complete, i.e potetially shippable? Or do you maybe mean the "SELECTED PRODUCT BACKLOG", i.e the sprint log?
If you really mean it, then I read it as after every sprint the whole product must be 100% complete. Can you explain that, please?
I undestand that there is some kind of a delivery after each sprint, but I take it that only the implemented features are delivered; not the whole product with non-implemented features stubbed out. Or am I wrong?
Cheers
Mikkel
9 January 2008 12:20
Hi Mikkel
You missed a key word from my post - I said make sure the product backlog *item* is 100% complete.
So, as you rightly say, I just mean the selected backlog items and not the whole backlog for sure...
Regards
Kelly.
26 February 2008 13:30
hi,
"Add up all the task estimates for the selected Product Backlog.
If they are significantly over the team’s Sprint Budget, reduce the number of Product Backlog items selected for the Sprint."
I have a bit of confusion; Is the "Product Backlog ITEM" a potentially shippable product or is the "SPRINT Backlog" made up of a number of "Product Backlog Items" a potentially shippable product?
If it's the Sprint Backlog, then what if removing some items from the sprint makes it not potentially shippable anymore? do we increase the sprint duration or something else?
thanks & regards,
Fahd.
20 August 2009 15:05
I have a few questions:
Can Agile be used for projects with Fixed scope, Fixed timeline, and a fixed budget?
Can you ever do Agile without a product backlog? E.g. i have a feature list and that is it, i dont know the number of story points etc but i am already 3 sprints into the project which we suggested would be 13 weeks (sprints) No sprint 0 nor stabilizing sprint.
10 September 2010 15:15
With more rigid contraints, maybe KANBAN would be appropriate.