Iteration-based delivery processes like Scrum usually deliver in two-week batches, but often our stories don’t fit this structure and we solve this by arbitrarily cutting up stories or stretching them across multiple iterations.
As Scrum is probably the best known iteration-based process and I’ve seen it implemented in multiple teams, I’ll use it as an example.
What does Scrum look like?
To demonstrate the issues with Scrum, it’s worth detailing the process:
- each batch of work or ‘sprint’ has set-up ceremonies at the start (sprint planning) and closing ceremonies at the end (sprint review and retrospective)
- there are Product Backlog Items (PBI or ‘stories’) that are moved from a Product Backlog into a Sprint Backlog in sprint planning. The team commits to completing all the stories in the Sprint Backlog
- when the Sprint has begun, the team gets on with the work, focusing on meeting the commitment
- at the end of the sprint the delivered product is reviewed and the retrospective allows feedback on (and ongoing improvement of) the process
This sounds pretty straightforward, but often stories can get quite big – even the small ones. And that’s where it starts to become unstuck.
The problem with PBIs
If a PBI is too big to fit into a sprint, it causes problems. Usually, when PBIs are moved into the sprint backlog, they’ve not been thought through well enough. Either from a user experience, a business logic or an implementation perspective.
Getting this thinking into a PBI is often called ‘elaboration’ and is generally a prerequisite of a PBI being accepted into a sprint. As practice has evolved, there’s often a per-PBI mini-waterfall process where a story goes through various stages of elaboration by the Business Analysts, User Experience Designers, User Researchers and Technical Architects.
This has two effects:
- developers get further from the end-users as they cease to be fed stories and start to get requirements
- the process of elaboration in conjunction with the development work breaks the time-box limits – there’s simply not enough time in a single sprint for a UX, UR, BA and then a TA to look at and elaborate on a PBI
In many organisations there are various strategies for dealing with this. Some go for the untracked elaboration where the non-developer delivery roles pick and choose stories to work on.
Most organisations go for a two-sprint cycle with elaboration done in sprint n-1 and stories developed and shipped in sprint n. Some even end up with a three or four sprint cycle with elaboration (n-1), development (n), QA (n+1) and deployment (n+2), giving an overall lead time of a story of six or eight weeks.
This can work, but expedited tickets often lead to specialised hot-fix processes and the structure leads to all stories having a fixed multi-week lead time, whatever the size.
Is there a better way?
Yes – and it’s called Kanban.
In a well-structured Kanban process there’s still a backlog and PBIs are still sized to the smallest size that will usefully deliver business value. And there’s still a commitment point but this isn’t necessarily fixed to a delivery point, instead the committed backlog is refreshed at more frequent intervals. When using Kanban, all stages of delivery are mapped, tracked and crucially, each PBI works through the delivery at its own pace, with progress being tracked statistically.
There are a number of benefits from this but I’m particularly calling attention to the individual tracking of PBIs through the process. This allows them to be the size they need to be rather than the size of the box they’re put in.
Who is ‘the stretcher’?
In Greek mythology, Procrustes (or ‘the stretcher’), invited passer-bys to spend the night in his iron bed. Because nobody fitted perfectly into it, he physically altered guests by amputating feet or stretching their bodies to fit.
What has this got to do with PBIs and Scrum?
By squeezing thoughts into a reductive category or enlarging ideas to fill the time you’re trying to control or predict the outcome of the unknown. This can have disappointing or unwanted consequences. Don’t be the stretcher – let your stories be the size they need to be.