Is there a flavor of Agile where user stories aren't sized?

(KC Casas) #1

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. :slight_smile:

(Augusto) #2

Hi keiscasas,

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:

If you have questions, just shout.

Thanks,

Gus

(Dirk) #3

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.)

(Heather) #4

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?

(KC Casas) #5

That question is interesting and reminded me of a funny meme I saw from one of the folks I follow in twitter. I tried looking for it and I saw a stackoverflow related question as well (the photo is posted there): http://pm.stackexchange.com/questions/12403/why-are-estimates-treated-like-deadlines

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. :slight_smile:

(Dirk) #6

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.

Even the teammembers had a tendency to do this: if there was a story on the board that was 16 hours and the dev worked on it for 6 hours, then he’d automatically put the time remaining on ‘10 hours’ (on a physical board).
Every time I’d see this happening, I’d ask them to think about the remaining work, and estimate THAT. Sometimes it went to 4 hours remaining, sometimes to 20 hours remaining. But I’d always stress that it is more important to know the current best estimate than hiding until the hours of original estimate had been spent and thén say they’d need 10 hours more.

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?’)
(Gabe Newcomb) #7

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.

(James Sheasby Thomas) #8

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.

(Jesper) #9

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…