1

Where agile estimation fails: Involving stakeholders to prioritize user stories

Involving stakeholders to prioritize user stories is important but difficult at the same time.

Stakeholder Management

In this article, I want to share with you a technique that helped me during a workshop to overcome huge differences between my stakeholders. I call it the Three Factor Prioritization and it helped me to involve my stakeholders to prioritize user stories. All in all, it helped my customers to understand each other’s demands and agree on a ranking. In my opinion, involving stakeholders in user story prioritization always pays off as it provides me with a better understanding of their problems.

On the other side, it is hard to come to a conclusion involving many stakeholders. Nevertheless, I felt that mine was quite useful compared to other prioritization techniques like:

The Workshop

Let’s start with the beginning…

In an old-fashioned way, we invited our stakeholders to a workshop spread over 4 days. Our two main goals were to understand and prioritize their needs. Obviously, creating a roadmap for the management was also part of this <img draggable= 

Our workshop consisted of three parts:

In the first part, we focussed on knowledge sharing and user story discovery. In addition, we provided training to them about our existing application.

Second, we had to prioritize their use cases to come up with a roadmap after the workshop.

In the end, my team and I groomed and estimated the user stories to transform the ranking into reasonable product increments/milestones to come up with a rough roadmap.

Where agile estimation fails

The second part of the workshop didn’t go as expected.

Initially, we planned 2 hours for the prioritization session and asked the product engineers to prioritize their use cases themselves. After 5 to 10 minutes, all three came up with different rankings. 20 minutes into the meeting we were stuck in useless discussions. Two of the four stakeholders had completely different first priorities.

In this situation, creating a ranked backlog of user stories for their needs was not possible.

The participants did not share a common understanding.

Therefore, I had to come up with a different approach to prioritize their use cases.

Three-factor Prioritization

Faced with the problem, it came into my mind that we could use dot voting. After a short time, I realized this doesn’t work. With “only” four stakeholders involved, we weren’t enough people to use it.For this reason, I came up with the idea to take a mathematical approach and let everybody agree on a score for each user story.

The trick here was to go a little bit into detail. They were not able to find a common rank/score for each user story before.

 

Nevertheless, they shared similar concerns about my product anyway. Therefore I transformed their three biggest concerns into scoring categories:

 

 Urgency

What happens if we don’t have this feature? Are the users unable to operate their business if we don’t have? In my opinion, this is comparable to the basic feature in the Kano model.

Usage Frequency

How many users will use this feature? Will they use it on a regular basis, e.g. every day.?

Reliability

Are there any legal or product compliance concern if this feature is not there? If those concerns are high, the score needs to be high here. (If you aren’t working for a big company and don’t have those concern, feel free to omit this category)

Estimating user stories

In short, all stakeholders had to agree on a single score per user story and category.

 

Actually, I think this is the trick in this whole thing 🙂

If they agree on the specific topics, they won’t complain about the overall ranking. In the end, it produces the compromise we are looking for.

 

To keep it simple we restricted us to three estimates:

1 = low

2 = medium

3 = high

 

Limited estimation values avoided discussions about each category. On the downside, this ended with a high density of user stories around a score between 5 and 7.

 

Hint: For up to 15 user stories this was ok. If you need to rank more than 15 user stories allow a wider range can be helpful.

The Results

Our first results looked like this:

Urgency

Frequency

Reliability

SCORE

Story #1

3

3

3

9

Story #2

3

1

1

5

Story #3

2

1

2

5

Story #4

3

2

1

6

Story #5

3

1

2

6

Story #6

3

3

3

9

Story #7

2

2

2

6

Story #8

2

1

1

4

Story #9

1

1

2

4

Compared to the beginning this wasn’t bad but we ended up with too many stories with the same priority. It wasn’t a ranked list.

As we didn’t want to start all over again, I asked the participants to suggest weights for each category reduce the density of the list.

As a result, we provided a weight to the last category “Reliability”.

Now, the list looked like this:

Urgency

Frequency

Reliability (x2)

SCORE

Story #1

3

3

3

12

Story #2

3

1

1

6

Story #3

2

1

2

7

Story #4

3

2

1

7

Story #5

3

1

2

8

Story #6

3

3

3

12

Story #7

2

2

2

8

Story #8

2

1

1

5

Story #9

1

1

2

6

Or as a ranked list:

Urgency

Frequency

Reliability (x2)

SCORE

Story #1

3

3

3

12

Story #6

3

3

3

12

Story #7

2

2

2

8

Story #5

3

1

2

8

Story #4

3

2

1

7

Story #3

2

1

2

7

Story #2

3

1

1

6

Story #9

1

1

2

6

Story #8

2

1

1

5

This was the list all stakeholders agreed on. Later, I used this list to update our product backlog with these stories

Afterwards,  I updated our roadmap and everybody was happy (for now).

If you are dealing with stakeholders on a regular basis

Conclusions

Managing stakeholders can be difficult. In this workshop I learned a couple of things:

 

  • Be honest and open with your stakeholders.
  • Reflect on your progress and the method while time is running.
  • If people are stuck, changing the method/perspective is not a problem. Explain precisely why you want to change the method.
  • Shared understanding is always the starting point. There is no need to discuss if people don’t understand the other participants.

A really cool method to be open with your stakeholders is User Story Mapping. It is helpful to create a common understanding in a group and visualizes your product in detail. If you want to learn about User Story Mapping I would love you to check out my post about “How to do user story mapping to define a product increment

Click Here to Leave a Comment Below 1 comments
Avatar
7 Tips to Create a Product Roadmap from the Backlog - Software Has Bugs - July 28, 2018

[…] If you want to read more about helping your stakeholders to rank their requests, check out my blog post about Where agile estimation fails: Involving stakeholders to prioritize user stories. […]

Reply

Leave a Reply: