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; } } }

How to handle teams with different ways of estimating

Wessel Donkervoort

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.

Comments

Troy Spetz_46oct3

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

Wessel Donkervoort

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?

Troy Spetz_46oct3

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

Welcome!

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

Quick Links

Find more posts tagged with

agile

advanced-roadmaps