Last week we talked about the Sprint. This week we’re going to kick off with Sprint Planning. The Scrum Guide defines Sprint Planning as
It recommends you do this by answering three questions. How is this sprint valuable? What can be done this sprint? How will the work get done?
In my experience most scrum teams by estimating Product Backlog Items, or PBIs (often called User Stories) and estimating how much work they can deliver by looking at their historical velocities.
This, in my opinion is wrong.
When teams do this it’s very easy for them to let the work drive the goals instead of the other way around. Rather than identifying what they want to achieve and working out how to deliver it they look at lots of granular pieces of work and cram as many into the sprint as possible, often losing synergy and coherence in the future.
It is always better for a team to look at what they want to achieve and what the various people can do to make that happen than to try and assign particular tasks to each person. This sometimes means that people’s capacity isn’t 100% utilised. But that time is infested in collaborating, learning, paying down tech debt, and supporting their team mates who are on the critical path. Far better than having everyone so stressed by an arbitrary deadline because some random user story was included in a sprint.
A team should always identify the next step forward for their product, the one which would yield the most value and plan the work required to meet that goal. They can use estimates to assess whether a particular plan for doing it is feasible. They shouldn’t focus on trying to fill up a quota of story points from estimates of varying accuracy.
It’s the PBIs which are planned to meet the sprint goal which we will use to verify our progress in the Daily Scrum sessions. This will be the subject of next week’s post so make sure you’re following the blog if you want to read it!
I’ve been reading Agile Estimating and Planning by Mike Cohn recently, one of the ideas introduced in the first couple of pages is that Agile Planning is very different to planning an Agile Project.
Mike explains that as you progress throughout the project the amount of uncertainty diminishes. He calls this the Cone of Uncertainty and argues that you should continuously revise your plans as you revise your priorities.
In an agile project change is embraced and priorities are adjusted so the team are always delivering maximum value to the business. The idea of agile planning is that your plans should develop as this uncertainty reduces.
Sprint 1 – We estimate this is about 12-18 weeks’ worth of work
Sprint 2 – we’ve done some of the initial R&D and underestimated several of the user stories. We now believe the total project will take 22 weeks
Sprint 4 – We’re happy with our 22 week estimate at the moment but we’re getting into some of the big refactors at the moment, we’ll confirm in a few weeks
Sprint 6 – the majority of the work is behind us and we actually got some quick wins. We are now aiming to deliver on the 20 week mark
Sprint 8 – we’ve mostly finished and will be delivering on the 20th week
Sprint 10 – your install will be on Tuesday 15th
As you can see progress reports and updates are continuously being fed back to the stakeholders but these are updates and estimates which refine with time rather than hard deadlines before the work has even begun.
I’m very intrigued by this idea. I do have my concerns how it would work when delivering to a 3rd party – several of our customers pull large testing teams together for UAT testing of our software. I’m not sure how they’d react to a “it’ll be 12-18 weeks” but I’m certainly interested enough to continue reading!