When I work with teams who have undergone Agile or Product training, these teams often have large backlogs of work and boast about the importance of prioritizing work based on value. I’m currently helping a team that went through such training years ago, but these practices of having a backlog and focusing on customer value have become insufficient in helping them solve the problems they currently face.
The team struggles with having options available for their people to work on, causing constant re-planning and frustration for the people in the team. We’ve just put into place some changes to the team’s backlog and started visualizing some information that we’re hoping will help improve their situation.
The Situation
A team I’m supporting received Agile coaching in the past, which included training teams on Scrum and Kanban, introducing Scrum Master and Product Owner roles onto teams, and creating a portfolio kanban system. The team, which develops a B2B service, has 35 people, including Product Owners, Architects, Scrum Masters, Developers, BAs, and Testers.
Soon after I joined, the product organization asked the team to create a roadmap for the next year as part of its annual planning process. That roadmapping is still active nine months later. As part of roadmapping, the team reviews and estimates all their potential initiatives and determines what can be accomplished within the next year. During this activity, maximizing customer value is the key decision filter for what gets prioritized.
Despite this lengthy road mapping activity and the team having 32 different initiatives in their backlog, the same issue kept coming up: “The team needs something to work on.” To address this issue, the team’s manager, the Product Owners and I looked at the backlog on the team’s portfolio kanban system to try and understand the situation.
This is what the backlog of the team looked like when we started:
- Everything prioritized and funded for the next year was placed within one kanban state, with unplanned items beyond that placed in another.
- The only information found in most cards was a brief one-liner describing the customer value of the work.
After talking about the situation we were in, we determined that:
- It was challenging to identify what items the team could pull in.
- The structure on the portfolio kanban reflected the organization’s planning and budgeting process but not the team’s value stream.
- Discussions on what work items the team could pull started by referring to the team’s original roadmap, which was outdated and lacked critical information.
- The key phrase we kept hearing is that we couldn’t pull in work because other teams “Weren’t ready.”
It turned out that dependencies on other teams was the key factor in deciding what we could pull in. This made sense as dependencies on other teams was also the most common reason for work in progress getting blocked.
The first step to improve the situation was making information on team dependencies explicit.
Visualizing dependencies on the backlog revealed that 12 of the 23 initiatives planned for the next year depended on one or more other teams.
Introducing the Idea of a “Ready Option”
Now that the dependencies were visible, the team’s manager and I asked our two Product Owners to help us identify which items were “Ready.” We defined “Ready” very simply, as “If the team could pick it up.”
Identifying ready options was different and new for the Product Owners. The definition of “Ready” had to be repeated a few times because the topic of value kept creeping back into the conversation. Product Owners wanted to bring in valuable, but not ready initiatives. “Forget about value.” I told the POs, “Value doesn’t help us if we can’t even work on the thing.”
The result of that activity revealed the following:
- Eight initiatives were ready.
- Three initiatives were actively in the process of getting ready.
- 12 initiatives were not ready and were not being looked at.
- Only one out of the thirteen initiatives with dependencies was ready.
When the team identified that it had eight options ready to be picked up, it felt like we had solved the problem until we heard from one of the Product Owners, “Those are ready, but we can’t pick them up.”
After a few more questions, we added another layer of information to indicate the value of each initiative to the backlog.
From this latest picture of the backlog, we discovered:
- The majority of the ready work was of low value.
- The product organization was reluctant to work on them because they served a small customer segment and didn’t align with any strategic goals.
- The two highest-value work items were not ready.
- There were multiple actions the Product Owners could take immediately to help move more work into “Ready,” which had been sitting for idle months.
This new picture revealed to the team that the two highest-value initiatives were not viable options to start anytime soon. It also revealed that if no action was taken, within a few weeks, the only available options for the team would be the low-value ones.
Getting Options Ready
Our discussion and this new view into the team’s backlog revealed that the team was neglecting the essential activity of getting high-value options ready.
Understanding that it’s unrealistic to remove dependencies completely, we talked about what activities would help get in getting options ready:
- Completing the organization’s formal intake process.
- Reserving capacity with dependent teams.
- Reviewing architecture requirements to identify teams needed for each initiative
- Securing key subject matter experts from other teams to act as enablers.
- Investing in developing new expertise within the team.
A simple definition of a “Ready Option” also started to form:
- For work with external dependencies:
- Completing the formal intake process.
- Having capacity with dependent teams reserved and standing by.
- Getting estimates from other teams for delivering any required work.
- OR: No dependencies on other teams.
Accounting for Dependencies In Roadmap Planning
How could dependencies on other teams within the same organization cause such havoc on what options our team could work on? One reason is that while my team was creating their roadmap for the year ahead and prioritizing by value, the nine other teams we depended on were doing the same thing. Nobody was looking across teams and taking dependencies into account when creating their roadmaps.
Looking more closely at this planning process and at why so many initiatives require multiple teams in the first place should help us understand the roots of the problem.
Conclusion
This new perspective on the team’s backlog and the idea of thinking about ready options is a new development, and I don’t have any results to share yet, but this activity which only took two hours has already given the team more clarity and more options to improve their situation.
Open Mode 