nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Estimation in jira

ADEEL AHMED_53732i

Best Method of Estimation in jira

T-shirt Sizing
Agile planning Poker
Orignal time vs Remaining Time

Comments

Himanshi_me2dvl

Hello @ADEEL AHMED ,

Welcome to the Community!

The best approach of estimation is subjective to your use case.

I am sharing a document that may help you decide what suits your requirement better, please consider going through :

https://www.atlassian.com/blog/add-ons/choose-best-methods-estimation-planning

I hope the shared information would help.

ADEEL AHMED_53732i

Thanks for sharing @Himanshi but which method is best for middle sized team in different time zone.

Nic Brough -Adaptavist-

All of them!

All those methods, and others, can work really well in all sorts of places. It's a very subjective thing, and the best advice I have is "ask your teams to work together to decide which one is best for each team"

In my experience, I tend to use several methods, not just one.

T-shirt sizing is not a good estimation tool. But it is really helpful when you've got a lot of backlog refinement to do, because you end up with 4-7 piles of cards where you know each card is going to be massive (epic candidates) or you can get a couple into a sprint, or you know you can get dozens into a sprint. This makes it a lot easier to prioritise and rank them against each other
Story point estimates are great for individual teams, but have the problem that people try to compare them across teams. This generally fails. Story points are not an absolute estimate, they are a relative one - "this card is 5 SP, because the next card is going to take our team 1/5th the effort to do (1 SP) and the one after 4 times as much effort (20 SP)". The emphasis here is on our team. One team's Story Point is very often a very different thing to another teams. (Real world example - before JSM was a thing, a client of mine was using Jira to track everything. One team's 1SP issues were all "password reset" or "add persons basic access to system". The developers 1SP issues would all be 2-4 hours of development time, not 5 minutes. Never assume story points mean the same thing to different teams)
Time estimates are a bit more waterfall - less flexible, less agile, and easier for people to plan against, but have a massive problem in that they are almost all inevitably wrong, and hence you really don't want to plan with them. I've never estimated 2 hours and actually used 2 hours to complete the job. They're not a bad way to do it, you just have to make sure your product owners and project managers understand that there is likely to be a massive error margin and the core number is not going to be right (for a 2 hour estimate, I expect my colleagues to expect a work log between 15 minutes and 6 hours)
And then planning poker. I personally love the poker. I'm utterly rubbish at the real game (against anyone other than my dad, who still owes me £10,000 ish from when he taught me 7-card stud), but it works really well for small to medium teams, even when remotely located (it is better in person). But I would use it alongside the other three estimate's you've mentioned, not on its own. It's great for working out the numbers/sizes your whole team would put on the issues. I worked in one place that printed its own playing cards - one deck with XS,S,M,L,XL, and XXXL cards (six per person, yes, so you can't sit on the fence right in the middle), and another with 1/2, 1, 2, 3, 5, 8, 13, 21, and "that's an Epic".

So, I apologise for the essay, but this is something that crops up a lot. I want you to know that you're not alone - people are struggling with this all the time.

But, the TLDR version: You need to do what works best for your teams!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

planning-poker