Iāve had one of my colleagues share some of the practices of the Agile project he is currently in. I found out they donāt size their user stories. Apparently, the leads make the commitments and cascade these to the rest of the team without their inputs. So I guess, naturally, the tendency would be for user stories to spill over to the next sprint, and he did confirm that is what happens. And thatās also the argument given for why they donāt need to size anyways because the work just spills over. But maybe if they did some sizing with the rest of the team, they would have improved on knowing whether they can commit something in the sprint or not.
I tried to google for whether thereās a flavor of Agile where they donāt size. Iāve heard there is such a thing as #noestimates, but having no estimates isnāt the same thing as no commitments, right? I reckon regardless of whether you size or not, your objective should still be to have the team in a better position to deliver its commitments.
So Iām just curious whether thereās such a flavor of Agile where user stories arenāt sized? And whether anyone can share any success stories of getting by without sizing (but of course still meeting commitments)?
I initially posted the question in Twitter/Medium but didnāt really get any responses. Iām hoping I get lucky here.
I have been practicing #noestimates with my teams for the last 4/5 years.
It is not only about not estimating stories, it is about doing the most important thing first, it is about reducing the batch size of the stories, and other things that are common in lean software development (more than in the agile side of it).
You can still forecast releases without estimating. You can in fact do probabilistic forecasting for this.
I wrote some of my learnings sometimes a couple of years ago here:
My team does Kanban. Since Kanban does not use timeboxes (but instead works priority-based), estimations are not necessary for the work to be fit into one sprint. Nevertheless, estimations can serve a purpose: they can trigger a discussion about the scope of a story and/or smart solutions. Basically, if estimations vary then that is reason to discuss the story more. The actual number doesnāt matter much. (BTW: we donāt do estimations, unless the product owner want to roughly know how much time a feature will take for his value-estimation.)
We just had a discussion about this on Wednesday at the testers meetup in Dublin. Someone was asking how could they get rid of estimates being used as hard deadlines for features. Itās not to say that the team wonāt deliver the product but it might not be delivered by date X that was originally estimated but then used as a hard deadline.
Perhaps this is different to not estimating size of stories but I think perhaps the sentiment is still the same.
We never came to a conclusion so I guess Iād further your question more and say how do we ensure estimates are used correctly if they are going to be used?
Anyway back to the question on āhow do we ensure estimates are used correctly if they are going to be used?ā Maybe itās a matter of educating the team and setting expectations within the team ā that when you do create these estimates, you agree on what itāll be used for so that you can pad it accordingly esp if youāre working with someone who seems inclined to treat it as deadlines.
In our project team, we use the user story sizes from previous sprints as a guide on how much we can commit for the sprint that weāre planning for. But only as a guide.
I invested quite some effort in unlearning people to use estimates as something āfixedā. It is an estimated, based on what we know now. Nothing more, nothing less. Tomorrow it can be higher or lower.
Once the team has unlearned this behaviour, rinse and repeat for higher levels.
Unacceptable behaviours:
hiding (so not updating your estimate as soon as you know it is inaccurate OR secretly working more on a problem without telling anyone)
holding people to estimates (āyou said Iād be finished in 4 hours!ā)
Acceptable behaviours:
making the estimate higher (People have psychological problems changing a 4 hour estimate in a 40 hour estimate, even if the (with new info) know that 40 is currently the best estimate. I try to encourage them to always be realistic, letting go of the previous estimate as an anchor for your current one).
asking clarification (āThe estimate changed from 20 hours to 4 hours. How come?ā)
My team doesnāt use estimates or sizing of stories, except for casual inquiries within the team (āHey Jen, how long do you think itāll be to finish this one?ā, etc.). We are in an odd position though where all of our deliverables are for internal customers, and usually without date requirements. I appreciate the simplicity of just grooming the backlog and working top down (we all have freedom to shift stories in the backlog whenever as appropriate).
In past jobs, Iāve worked hard to avoid giving estimates. I find that no matter how you couch it, giving ANY time estimate to an external person (especially a sales person), will be misremembered. Any caveats or percent of confidence attached to the estimate WILL be dropped and only the estimate will be remembered. And then it gets converted mistakenly into expectations. This is the typical pattern of trying to be Agile within a company where only the Engineering folks have embraced it. Itās a constant battle if you canāt get the business on board with an Agile philosophy.
One more thing: even if someone mistook an estimate for a commitment and you correct it later, it doesnāt fix the problem. Theyāve developed an expectation on the delivery date and possibly even staked their reputation on it (to some degree) by communicating with other people about it. Better to never let it start by avoiding an estimate.
On my most recent Kanban project, we used āGoldilocks estimationā, which works like this:
Group requirements by epic, creating new epics as needed.
For each requirement, break them down into stories that are:
Roughly the same size (e.g. 1 day or less)
Testable in isolation (if possible)
Donāt include unnecessary implementation details (i.e. itās up to the team to decide how they are implemented during example workshops etc.).
If a story canāt be broken down to the same size as others, mark it as ātoo bigā.
If a story is so simple that it will be significantly smaller than the others, mark it as ātoo smallā.
If the requirements arenāt detailed enough to be broken down into stories of roughly the same size, donāt turn it into a story until more information has been obtained (or create a placeholder story)
These stories are added to the backlog and prioritised by the client - normally all the stories relating to a requirement are kept together.
At the start of each iteration we can make a rough guess at how many stories in the backlog weāre likely to get through, but without ācommittingā to a specific number of stories. For example if the stories at the top of the backlog are each roughly a day, and none are ātoo bigā, then one developer will be able to get about 5 of them done in a weekly iteration.
These ā1 day or lessā guesstimates donāt include testing time, UAT time or time spent fixing bugs, but for testing time we generally assume it will be about half a day or less per day of development.
There are many flavors of agile (and many flavors of testing too). Some contexts donāt need to size user stories, others do. And thatās OK, but interesting to me why the difference.
Recently on an agile project I did; during sprint planning we broke the stories into tasks, estimated the tasks and accumulated the effort to the story (tools support MS TFS). If needed we shuffled stories to/from the backlog or across sprints. We had a MVP approach, rather than fixed scope / deadline. Perhaps thatās whyā¦
