Agile Roles in Practice – To Do or Not To Do
One of the biggest challenges in a defined Agile environment is to understand the scope of your role in this organization but also to remain faithful to it. Even with the best of intentions, you may be tempted to deviate from your role so you can provide an extra service to your customer, produce deliverables quicker, make things easier for everyone … In this kind of case, you have to remember that all the roles defined within the Agile framework are logically intertwined with each other. Therefore, any deviation can have exponential consequences on the whole system in the worst case.
Let’s start with the following contextual setting:
- Role: Product Owner (PO)
- Situation: Iteration Planning (IP).
As you may know, the PO is a specific role in an Agile team in charge of maximizing the value delivered by the team and ensuring that the team backlog is aligned with customer and stakeholder needs. It is commonly said that the PO is the primary link to business and technology strategy[1]. To make this possible, the PO will take the lead in the IP event where the team members determine how much of their backlog they can commit to deliver in the upcoming iteration[2]. By prioritizing the backlog items and being the owner of the planning, the PO plays a key role in the Delivery capacity of the team, both in terms of Velocity[3] and Predictability[4] which are key metrics in Agile.
Now, what should you do as a PO if one of your regular customers comes and pushes you to plan a work item as a top priority in the next iteration?
As a PO, customers and other parties will often ask you to be flexible with your planning. It’s not a bad thing in itself but, at the same time, you have to protect your roadmap and other stakeholders, especially your team as they might be impacted by your decisions. Consequently, you have to put all the chances on your side to take the good ones.
To Do’s
- Take into account a small margin in your velocity so you can always add some extra amount of work – if necessary – without jeopardizing the rest of your planning.
- Confirm the priority with the customer by challenging the added-value of this extra work item with your initial planning.
- Based on your Definition of Ready (DOR), make sure that the requirements coming from the customer are clear and complete.
Not To Do’s
Prioritize this extra work item on your planning:
- Only based on your good relationship with the customer or under the pressure of some urgency.
- Knowing that it will impact your velocity and/or predictability and therefore your other customers.
- Even though it doesn’t meet the criteria of your Definition of Ready (DOR).
Based on our field experience, we have observed that many Agile teams and POs plan backlog items without applying any DOR[5]. It is usually the sign of a lack of Agile maturity and it may easily result in repetitive delays, poor quality of deliverables and growing frustration for the team members.
Good news is that a strict mindset is enough to help improving this kind of situation! With the support of your Scrum Master (SM), take the opportunity with your team to define relevant DOR that can adapt to the multiple scopes of your core business. It will be your responsibility to make sure that these DOR are met at every IP. In return, your team will drastically increase the probability to improve its Velocity and Predictability as it will decrease the risk for your team to be blocked with non-refined items.
As conclusion, as a PO, you may be flexible with your customers as long as you remain firm with your acceptance rules.
[1] https://www.scaledagileframework.com/product-owner/
[2] https://www.scaledagileframework.com/iteration-planning/
[3] Units of work that a team can complete in one iteration
[4] Units of work that a team delivers as planned
[5] Set of criteria defining what is required to make a backlog item ready to be developed by the team and actionable in one iteration.