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.
Priorities, huh?
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 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 always all user stories had to 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 nor for 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 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 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 spring wasn’t visible for him.
When the sprint started the team took a screenshot of the Product Owner’s backlog (in jpeg), 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 reasons why a team member finished a user story that was at the bottom of the sprint backlog were because it was easier to do it, or because they didn’t understand other user stories and then picked one which was clear to them. Or one 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 from 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 in stead of working on many user stories. I showed them how “stop starting – start finishing” from Kanban helps 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 morale 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 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 ask 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 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, not even Scrum, where they only had several days of training. Things like agile coaching and refreshment workshops can be used to support teams when adopting agile.
