Often the number of needs that impact a product is very high. We know that the Product Owner for a given product must be a single person, in order to avoid conflicts and confusion about the ideation process of the product itself and about the teams that work to make it a reality.
But the fact that the Product Owner must be a single, clearly identifiable person does not mean that this person is alone in the face of the complexity of the product. All the people impacted or interested in the product (the Stakeholders) collaborate in the identification, justification and prioritization of the product’s characteristics.
In this sense, we present here a very interesting activity that helps the Product Owner to carry out an initial prioritization of a large number of needs. The Eisenhower matrix.
Needs prioritization applies in specific meetings that serve this purpose. They can be inside or outside the product execution process. They can be carried out before starting the product construction projects; or once they have been launched. Therefore, we can include it in the category of Refinement meetings contemplated by the Scrum.
The tool we will use in this activity is the Eisenhower Matrix. It consists of a board that is divided into four areas. Each of these areas gives an indication of the importance and urgency of carrying out a specific feature or need of the product. Thus, we have the following board:
In general, we can establish without any fear of making a mistake that a task with low urgency and low importance will have a low priority in the Product Backlog of our product. Likewise, a need classified as important and urgent will have a high priority.
The remaining options (high importance but low urgency, or high urgency but low importance) can be the subject of debate among the participants of the activity, who will have to consider which grouping is more priority.
As always, my recommendation for these activities is not to exceed 1 hour in length. Explaining the needs individually to ensure that participants understand it in an aligned way takes a lot of time. We must make sure to choose a number of activities that does not exceed the time of the meeting. It is probably preferable to have several meetings of an acceptable length, which guarantees everyone’s proper attention, than a single marathon meeting that leaves us with the doubt whether the classification obtained is really the correct one.
We must arrive at the session prepared. The Product Owner already has the cards with the description of each of the characteristics or needs that he wants to prioritize. In addition, it is advisable to have access to the Product Backlog in case there is a need to clarify any doubts regarding any other need present in this record.
At the same time, the attendees have had access to this information prior to the session, so that we can focus as much as possible on explaining a need without having to waste too much time putting the participants in context.
At the beginning of the session, the Product Owner explains the working rules and presents the matrix. If necessary, he can establish a debate with the participants about the prioritization that the needs that are located in the areas of low importance and high urgency, and high importance and low urgency should have.
From here, the organization of the meeting is quite free, and depends a lot on the complexity of the needs to be explained and the ability of the participants to make decisions. A conservative approach would be for the Product Owner (or the person with the most knowledge about one of the needs) to explain a need to the attendees and ask the group for a decision in order to place it in the appropriate area of the quadrant. Once this is done, they would move on to the next need until all the needs foreseen in the session are completed.
Another more dynamic approach is to place the need cards on the table and ask the attendees to choose one of these cards themselves and place it in the matrix. Afterwards, they must justify to the rest of the attendees the main reasons why they have placed it in that area of the matrix, being able to establish a debate to reach a consensus, and changing the position of the cards if necessary. If the number of attendees is high enough, we can ask for the creation of working groups that are responsible for a certain number of cards.
The Product Owner, who is the one who moderates the session, must be available to resolve doubts about the scope or characteristics of the needs being prioritized. And he ensures that the group focuses on reaching a sincere consensus on each of the needs.
It is very convenient to explain at the beginning of the session that the objective is not to reach a consensus on the “effort” necessary to make the needs a reality (this will be done by the technical team later). The purpose of this session is solely the priority. Let’s not confuse “easy/difficult” with “important/urgent”
Cómo usar la matriz de Eisenhower para priorizar tareas? (video tutorial) Trello.com (https://blog.trello.com/es/matriz-eisenhower)
Introducing the Eisenhower Matrix Eisenhower.me (https://www.eisenhower.me/eisenhower-matrix/)