Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to handle teams with different ways of estimating

Hi,

 

Let me start off by saying that I do understand that story points are a relatively measure to estimate work. That means that one story point cannot be compared cross-team.

With that being said here is my first question:

some time ago I was told that it is handy (for Portfolio for Jira) to have teams estimate in the same range. So let's say have all teams estimate using 1, 2, 3, 5, 8. Knowing that an 8 point story is not the same in each team but indeed is the biggest story they can commit within a sprint.

 

Now I have a team that is using estimates within their sprints that go as far as 34. So I got teams that have story points that not go further than 5 or 8 and I got one team that has 34. Now to be honest I don't see the issue but I can't shake off the story I once was told that it's better to have estimates in the same range when using Portfolio for Jira. The algorithm is still able to create a trustworthy plan and it wouldn't make a difference if that team is not using 34 for their biggest story but 8 right?

Any thoughts on this?

 

Second question: I got some teams using Kanban. I want to use the "workaround" in which all stories need to get 1 story point and the throughput time of the team (amount of stories they finish per week) is their "velocity" in a one week "sprint". However I have a team that goes all over the place. Sometimes they have big tasks on their kanban and sometimes they are small. This means that sometimes their throughput is a few stories and the week after it's a lot.

It feels like that this team just needs more agile coaching and cannot be solved within the tool. I was just wondering if somebody has experience with this and what did they do to tackle the issue?Looking forward seeing your responses.

2 answers

We use JIRA server 7.12 version.

 

We used to have 2 separate teams (i.e. one in Europe, one in India) which were using a different total number of Story Points per day (i.e. for sprint backlog estimation).

This situation required 'SP conversion' between the two teams and made generating SP summaries (within a single JIRA project) useless.

Ultimately, we had to align both teams to use the same SP estimate so that 1 SP (in Europe) meant 1 SP (in India).

 

It seems your life is further complicated by the fact that you have both Scrum and Kanban teams.

 

I think you may have to settle for using 'time estimates' instead. Because an hour is the same length of time, regardless of team type (Scrum/Kanban) or location (here/there/everywhere).

 

For example, Mike Cohn advocates hour estimations for sprint backlog and SP estimations for product backlog. See Link.)

Thanks for the answer @Troy Spetz! It's not clear to me how it became a problem for you guys. Did these two teams pick-up the same work from the same backlog?

 

If one team says a story is 5 story points while the other one says it is 50 it doesn't matter if the velocity also differs roughly with factor 10 right?

 

The big downside that I see is that the total calculation on initiative level will become "useless". If an initiative gets a 500 points calculation it doesn't really mean anything. However that initiative planned end date is still based on what these both teams can pick up.

 

So again I circle back to my question to you: how did this become a problem for you?

@Wessel Donkervoort You have correctly identified the problem: Total calculations, across 2 teams, were useless because they were not using the same SP estimation method.

 

For example, if you wanted to know the total SPs for an entire release's worth of effort (from two teams), you'd have to summarise the 2 team's effort separately -- and then do a conversion so that apple=apple.

 

By having both teams using the same SP estimation method (i.e. 1/2/3/5/7 SPs), this conversion was no longer necessary.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Agile

Join us LIVE: Atlassian & Experts Talk Research & Insights @ Scale

Hello all! What have you learned from your customers lately? Our live-streamed series continues by exploring CX, UX, and the power of research & insights at scale with Leisa Reichelt, Head of R...

270 views 3 6
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you