Drop the sprint planning meeting
Sprint planning is amongst the most time consuming activities for development teams. One could argue that the value you get is not proportional to the effort you put into these meetings. With some effort you can drop sprint planning meetings completely. Here’s how.
1. Focus on prioritisation and not sprint scope
Most businesses must be responsive to their customers and you’d like the flexibility to move requirements up the queue if necessary. Fixing sprint scope is counterproductive to this. Of course, this can descend into chaos if there aren’t a few rules in place. So you need to establish three guardrails.
Never context switch developers and testers. Work-in-progress must always be inviolate. All you can influence is the next item in the queue, be it a story or a bug fix.
The product manager ensures that items in the “ready for development” lane are always in descending order of priority.
Nothing can enter the “ready for development” until it meets the DoR (definition of ready) criteria for your team.
2. Measure throughput and cycle time, instead of velocity
If your team isn’t delivering to a contract you’ll overrun, measuring story points isn’t as important to us as getting stuff out of the door. Instead, measure yourself on these two indicators.
Throughput; i.e. number of items delivered per sprint.
Cycle time; i.e. the time it takes for an item to go from an “in analysis” state to your definition of done (i.e. DoD).
I want to call out a couple of pitfalls and considerations here.
Measuring throughput works well when you size items to have a similar size. Between the team’s lead developer, tester and product manager, eyeball stories to check that they’re roughly the same size. This’ll be a rough estimation exercise. Can you be 100% sure that all stories are exactly the same size? Hell, no! You aren’t aiming for accuracy, though. The trick with this approach is to know that if you eyeball for consistency, then over a sample, you’ll regress to the mean.
Your teams can still negotiate scope. Often, when analysing stories, you’ll notice that the scope differs from your initial assumptions. Feel free to slice the story down in other similar sized items and make sure your stakeholders are aware of the impact.
Measure throughput only for functional stories. This is a good thing. If you see your throughput going down, it often means that you have too many defects slowing you down. This may mean that you must up the ante with test-driven development and improve your regression test suite.
The cycle time metric forces you to optimise your system. Since the measurement applies to all functional items from “in analysis” to “done”, it discourages you from piling up a huge inventory of stories in analysis. You must communicate rigorously with your stakeholders to focus on the things that are important. At the other end of the process, testing may become a bottleneck, so not only will this encourage you to improve your testing approach, you may also get developers to double as testers when necessary.
3. The sprint exists only as a common denominator for measurement
When you examine the tweaks in this process, you’ll see the sprint doesn’t need as much ceremony any more.
You’re pulling work from the top of a prioritised queue. The team gets as much done as possible and doesn’t pause because it’s the beginning or end of a sprint.
Productivity measures still exist per sprint. They’re not as detailed as story points, but they’re simpler.