Priorities are essential if you want to quickly deliver value. But they only work if they are visible for the team and product owner, to assure that they are aligned on what needs to be done. Here’s my story about how visualizing priorities helped a team to deliver more value.
In an earlier post, I explained how you use visualization for making things visible; things that people don’t see or have different views on. It enables people to discuss them, share their views, and align their thinking.
When I was giving an in-house Agile/Scrum refreshment workshop for a client I noticed that some of the attendees looked surprised when I talked about using priorities in the Sprint Backlog. Based on my observation we started discussing this.
It turned out that the development team always gave a commitment to a full set of user stories at the start of the Sprint; their view was that it was a binary goal and that all user stories always had to be delivered at the end of the Sprint.
Normally, every individual user story should have value, so making this a binary Sprint goal didn’t sound like something that was helpful for the team or the Product Owner. But it turned out to be even worse…
It’s Delivery Jim, But Not as We Know It
During the discussion, it became clear that the team never managed to live up to their commitment of delivering all their stories. They considered all user stories in the Sprint Backlog to have the same priority: “finish in this Sprint.” During the Sprint, team members would work on many stories at the same time, losing time with multitasking and not being able to finish them. It also often happened that user stories which were at the top of the backlog weren’t finished, where as stories at the bottom were ready.
The Product Owner didn’t see how the team picked user stories during the Sprint because the development team had created their own separate backlog for the Sprint. What the team did during the Sprint wasn’t visible to him.
When the Sprint started, the team took a screenshot of the Product Owner’s backlog (in jpeg format), and then created backlog items for each story in their own internal development backlog. The Product Owner didn’t have access to this backlog, and since the development team and the Product Owner worked at different locations, he didn’t notice what happened during the Sprint.
Clearly, there was a disconnection between the Product Owner and the team regarding priorities of the user stories, and things weren’t visible for them. The earliest time the Product Owner saw the result of this was during the Sprint review.
Often, then, the team stated that they had to work on certain user stories due to technical dependencies. Other often-stated reasons as to why a team member finished a user story that was at the bottom of the Sprint backlog was because it was easier to do, or because they didn’t understand other user stories and then picked one which was clear to them; or that a team member liked to do a specific story.
The Product Owner, of course, wasn’t happy with this. For him, the priority mechanism didn’t work, since the team was finishing stories in a different order than was requested by him.
Visualization to the Rescue
My advice to the Product Owner and the development team was to visualize progress using one backlog, both for the product backlog and for the Sprint. When planning a Sprint, the user stories can be tagged to indicate that the team should work on them in the current Sprint.
The priority from the product backlog would set the initial priority for the Sprint, but this should be discussed in the planning at the start of the Sprint where the development team and the Product Owner can agree to change it. The result of the planning should be a prioritized Sprint backlog accepted by the team and the Product Owner.
My client accepted my advice and started working as proposed by me. As they were using Jira, it was easy to realize a shared backlog to plan their Sprints.
They also started estimating their user stories in story points and tracking their velocity. The team became able to deliver more user stories since they focused on finishing high priority user stories instead of working on many user stories. I showed them how “stop starting – start finishing” from Kanban could help them to deliver more value. There was less task switching, and no more time wasted on low priority tasks.
Delivering the Most Valuable Stories First
The moral of this story is, visualization works! Once the Product Owner saw what happened during the Sprint, solving the problem and further improving the collaboration between the Product Owner and the team was easy.
Visualization helped the team to deliver more value as this story from working with a client shows. A book that I recommend is Visualization Examples, it contains ideas on how to visualize things and inspires you to try new ways to use visualization in your daily work.
As a trainer and coach, I helped the team and Product Owner by visualizing how they planned and tracked their work. I asked powerful questions, provided suggestions how they could work together more effectively, and gave them feedback and support when they implemented changes in the organization. This enabled them to discuss their way of working, decide what they would change, and how to improve their results.
The organization had received training in Agile and Scrum (from another trainer), my assumption is that the concept of prioritization was taught in there. But let’s be honest, you can’t expect people to fully understand Agile, or Scrum, where they only had a few days of training. Things like Agile coaching and refreshment workshops can be used to support teams when adopting Agile.