Made to measure

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!

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

Kelly.

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…

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

In The Zone with Marcin Zasepa

Welcome to the second in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Marcin Zasepa, CTO at Homegate AG in Switzerland. Every episode will be approximately 30 minutes

Read More »

In The Zone with Sasha Bilton

Welcome to the first in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Sasha Bilton. Every episode will be approximately 30 minutes long, and we aim

Read More »

Case Study: DAZN Data Engineering

Find out how 101 Ways helped DAZN improve their existing data warehouse as well as planning and setting the foundations of the new cloud-based data platform. Click here to download the full case study. Get in touch with a member of the 101 Ways team if you would like to discuss ways in which we can help you and your company

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?

London

101 Ways Limited
41 Corsham Street
London
N1 6DR
United Kingdom

Manchester

101 Ways Limited
No.1 Spinningfields
Quay Street
Manchester
M3 3JE
United Kingdom

Amsterdam

101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam
Netherlands

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.