Home > Articles > Programming

  • Print
  • + Share This
This chapter is from the book

Ranking User Stories with a Dot Voting Method

Although, according to the development team, the product owner is perceived as the one who decides the ordering of the backlog, it is actually not his decision. He must rely on stakeholders who are the ones who decide the importance of each story.

For the product owner, ranking user stories is actually a contact sport with stakeholders. It requires that he brings all his senses to the task and applies the best of his thinking, his feelings, and his communication skills to the challenge of facilitating decision making. The product owner is a facilitator, not a decider. Because he understands the process of grooming the backlog, he can guide stakeholders.

As mentioned in Chapter 3, “Discovering Through Short Feedback Loops and Stakeholders’ Desirements,” you can picture the communication between builders and stakeholders as a large room swathed in darkness. The product owner is in the room having conversations with stakeholders and what he hears is a cacophony of dissident voices. Because there is no light, little knowledge is derived from the situation. Now, imagine that the voice of each stakeholder emits a color when speaking.

The product owner steers the conversation by asking stakeholders what is the most important desirement. Soon, he will be surrounded with multicolored fireflies representing stakeholders’ desirements. By forcing the writing of the desirements as a user story, this can simplify the answers and increase the likelihood that the same desirement can repeated by several stakeholders. When user stories begin to accumulate, all the different colors merge, creating sparkling white lights. Order springs from the cacophony. These white lights are the important stories, those that the product owner must rank at the top of the backlog.

So far, the ranking process as described may seem abstract. Forget the abstract to be more practical. Usually, when discussing ranking, authors prefer to present the most common techniques, such as binary search tree, Kano analysis, MoSCoW (Must-Should-Could-Would), or other numeral assignment techniques. Now do the same by using one of the preferred methods: the dot voting technique (also known as spending your dollar technique). This established facilitation method is widely used by workshop facilitators for prioritizing ideas among a large number of people, and for deciding which are the most important to take forward.

The method is summarized as follows:

  1. Post the user stories on the wall using yellow stickies or in some manner that enables each item to receive votes.
  2. Give four to five dots to each stakeholder.
  3. Ask the stakeholders to place their votes. Stakeholders should apply dots (using pens, markers, or, most commonly, stickers) under or beside written stories to show which ones they prefer.
  4. Order the product backlog from the most number of dots to the least.

When you are done with this first pass, it is almost certain that the stakeholders will not be completely happy with the outcome of the vote. If that is the case, you should review the voting and optimize it. Here’s what you can do:

  1. Arrange the votes into three groups to represent high, medium, and low priorities.
  2. Discuss stories in each group.
  3. Move items around to create a high-priority list.
  4. Make a new vote with items in the high-priority list.

The goal during this review is to start a discussion about each group. Discuss which user stories are a low or medium priority, and which must be delivered in the near future. Why are they low priority? After discussion, stakeholders may agree to move them into the high-priority list. Also, discuss the stories that are almost high priority and decide if you should move them in the high-priority list. When you are done with the discussion, repeat voting, this time using only the items that belong to the high-priority list. Finish this second vote by ordering the product backlog from the most number of dots to the least.

Identifying the user stories that are top priorities is the first step of a two-step process. The second step is to ensure that the stories are small enough so that the team can build them in a sprint. To achieve this goal, the product owner must shift focus and start discussions with the development team. Unlike stakeholders, the team members are the ones who can measure the size of user stories.

Sizing requires a rough understanding by the development team of the user experience. The user experience enables stakeholders to discuss the success criteria. These criteria say in the words of the stakeholders how they expect the software to behave.

During this second step, seek to quickly define success criteria, so the team estimates the size of stories as soon as possible and with minimum effort. A storyboard is the perfect medium for achieving this goal. If user stories help monitor conversations with stakeholders, storyboards help to illustrate expectations rapidly and cheaply. They are concrete examples that provide the explicit information required by the development team.

  • + Share This
  • 🔖 Save To Your Account