I’ve not really understood the no estimates movement. I’ve read a bunch of blog posts and followed the twitter hashtag and discussed with friends and peers, but it just seems like a different kind of estimating, albeit using empirical evidence (not that story points don’t).
Anyway, the secret is this: INVEST.
If your stories adhere to this acronym, then you’ll be able to do #noEstimates and, by “adhere” I really mean, be “Independent”. I believe this is the one most important things about the movement – being able to make decisions about what to build and deploy, how to prioritise and project comes down to the quality and size of your stories.
Recently I had a retrospective with one of my teams after two failed sprints. They cited unplanned tasks as one of their issues and suggested that perhaps the scrum framework wasn’t right for the kind of project they’re currently doing.
To give some context, this is a long running team on a long running project with no kind of release windows. One mistake that we did make was that there wasn’t a ‘Sprint Zero’; a chance to look at the project as a whole and do some time-boxed up front planning for a sprint. However, we’ve entered two sprints without some knowledge of how we plan to do things and it’s caused bad sprints.
When we began to plan the current sprint. There were some ‘technical’ stories in the backlog, for large chunks of backend work which had other stories dependent on them. They were all estimated quite high, without acceptance criteria or the ‘As a …, I need …, so that … .’ stanza to support them. This is fine, the stanza is only important when it provides value and usually not for technical stories. One of the problems was not having acceptance criteria, so the first thing we did was to define those.
After that and to get to the crux of the post though, I asked :
Describe this story in high-level steps.
To which the team discussed what would be done to do each story, we defined the tasks at a high level (much like you would do when planning proper), but after each task was defined, I asked the team to estimate the tasks in story points. It was an eye-opener!
The tasks were all coming in with estimates of 2’s and 3’s. Which meant that, when the broken down, estimated tasks were added up, they were more than the original story. This usually happens, but it was an ‘Ahha!’ moment for the team. It allowed them to think more abstractly about the work. It’s not the plans that are valuable, but the planning!
To compound the issue, we’ve been getting hung up on the idea of each story delivering functionality which we can demo. While this is a noble goal, I’m sure it’s not always possible. This was causing huge estimates on stories and, as we know, bigger estimates mean lower accuracy on that estimate. With this constraint removed, the team breathed a sigh of relief and began writing stories which were meaningful and well sized. What actually came out of it is that, once we’d broken them down, we could see that for some of them, there actually were things we could demo; speed improvements on database queries and data integrity which DO provide value and so can be demoed.
Finally, when choosing the stories to add to the sprint, the team committed to work which they used their gut feel (and their velocity, but only as a guide) on what they could fit in. I went through each story asking, ‘Can we do this and all the previous stories?’ They committed to less than they would have had they just added the original stories. Meaning that, the non-decomposed stories were causing them to overcommit without recognising it.
So, if you’re failing sprints due to unplanned work cropping up and causing you to have over-committed, then ask for high level tasks on how to complete the story and estimate each of these tasks as if it were a story, you can go too far by decomposing each task to a story level, but if you’re finding this is the case, then your failed sprints probably aren’t caused by your stories.