Step 4: sprint planning (tasks)">
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.
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.
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!