Estimating

[ben-sagar]

We should define and agree standards for how we do estimating of development effort.

[irisfaraway]

Does this cover estimating for sprints and individual stories?

For smaller estimations, I'm a bit wary of trying to standardise this across teams as I think it would be difficult – for example, our team uses Fibonacci numbers to estimate our Jira tickets, but others might want to do t-shirt sizes or something.

This is also something that affects people outside the dev discipline, as other members of our team (like designers or user researchers) also estimate their work in the same Jira board, and we have a shared understanding of what a "3" looks like vs a "5".

It also took us all a few sprints to get into the groove of this.

So getting the whole department to agree a common "3" or "medium" feels like it'd be quite an endeavour!

If this is more about estimating large projects (eg "I think it would take 2 devs 6 months to build this") then ignore my ranting :)

[johnwatson484]

I agree with @irisfaraway that it wouldn't be sensible to make this a standard. Story point numbers are always specific to a team's understanding of the value which is difficult to share.

I'd also say there are valid cases for using points vs t-shirts. I tend to use t-shirt sizing to give a high level estimation of a project's delivery when little is known to get an indication of overall effort, but use story points when actually refining the lower level tickets required to deliver.

But what I do think will be useful is a guide explaining the different techniques that could be applied as well.

Within FFC we have the below in our dev guide. You'll see that we've deliberately not been prescriptive into what teams should do so we could keep these standards as simple as that?

I think we should emphasise the benefits of scoring tickets as I've always found it more beneficial than when I've worked on teams that don't. Taking delivery estimation side away, I find it helps the team gain a common understanding of a ticket and acts as another mechanism to further refine the ticket through discussion.

Sizing tickets

Teams may find it beneficial to score tickets to help plan their sprints and calculate delivery estimates. There are several techniques that could be applied to aide with this including:

• Scrum Poker
• T-shirt sizing
• Large, uncertain, small
• The Bucket system

[Cruikshanks]

I have stood in for @bensagar-ea on what are known as shaping calls where an estimate is expected to be given on the number of dev's required, and how long for at a project level.

If there was something more formal for those times we are required to estimate a project in its entirety or non-agile pieces of work, it might mean those calls are not so intimidating and our responses would be more than an individual's best guess.

That said, I'm also happy with the current process of letting @bensagar-ea do them all, so there is no real driver for this!

But 💯 agree with @irisfaraway and @johnwatson484 . Steer clear of trying to get involved in how agile teams do this. There be 🐉 !