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!


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
- 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 #9: Finish when you said you would
- Step #10: Review, reflect, repeat…

7 Responses to “Step 4: Sprint Planning (Tasks)”

  1. Artem Marchenko says:

    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.

  2. Anonymous says:


    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?


  3. Kelly Waters says:

    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…


  4. Fahd says:


    “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,

  5. Anonymous says:

    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.

  6. Anonymous says:

    With more rigid contraints, maybe KANBAN would be appropriate.

  7. Anonymous says:

    My company is in the early SCRUM. We are still implementing automated testing and deployment, so there are manual processes required until the automation will take over.

    Right now, we’re asked to plan for a PBI for Deployment activities which will affect the development time of the last Sprint before a Release. We plan for this by creating a PBI & tasks within the Sprint Planning Meeting, so we plan for the added time that not having automation will take to complete our roll out to production.

    How to do other Agile teams who are still adoption the automation of builds and deployments, handle the planning of deployment related tasks? Is there another way that might be better or easier for us to try?

Leave a Reply

What is 9 + 5 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”