The “Hayes” Line

(5 Minute Read)

The first thing that I was asked to do as a Product Owner was to take control of the ecommerce product backlog. In most of the books about managing a backlog, they start with a new backlog; but I was inheriting a backlog that was already in progress. Approaching an existing backlog seemed a bit daunting at first, but my boss told me that I personally ‘didn’t have to be an expert on the stories in order to create the PBIs. Finding a way to do it or fix it becomes a requirement for someone else.’ My main objective was to make sure every story had a user story (the what and why behind the story), acceptance criteria (what needs to be completed to be considered done), and a stakeholder listed (in case there are questions and to demo to) in order to be ‘ready’ to be refined by the dev team.

I needed a way to make it clear for our stakeholders, who were primarily executives and directors that would need to be able to see at a glance what the priority order was. Chris Hayes suggested a technique that by creating a PBI that was simply marked as –The Line– it would act as a clear focal point for everyone. He added the line at the very top of the backlog under the stories that were already approved and ready to be worked on in the next sprint. This allowed for the stakeholders to look at the backlog and know which ones they could advocate for and which ones would be ready to be worked on by the team. It also helped me to keep track of which ones have been reviewed and which ones need more information. Only the approved items (items that could be pulled into the next sprint) were allowed above the line. Once the development team refined the stories and estimated the effort it would take to complete the story, it could be marked approved and then moved above the line. There should not be any new items entered above the approved ones. If a PBI or a bug needed a spike, then you would create a spike PBI and move it ahead of the original but you don’t have to move down the original story.

Starting from the top of the backlog and working down, I started by reviewing all the existing PBIs and bugs in the backlog. I reviewed the information in the stories and would reach out to the stakeholders to see if the request was still valid and add more information. Since anyone with access to the backlog was able to add whatever they wanted to it, there were many duplicates and many stories that had no information except for the title or had very little information. We did change our process so that all new stories would have to be entered by me with the stakeholder. That way I got more experience and knew what they were asking for specifically and also helped the stakeholders understand what kind of information would be needed for every story going forward. The first time I went through the backlog, it took me almost three weeks and I reduced it from 375+ items to under 200. Once we started going through these, the developers were happier with having more consistent and more accurate information in every story and the stakeholders were happier to know what information was needed and to know that someone was keeping track of what was in the backlog.

After a couple of months of adding stories this new way and clearly seeing which stories were ready to be prioritized and worked on, the next problem that we ran into was stakeholders not understanding which stories were going to be refined and approved. This time we created the — Product Owner Refinement — line, which stakeholders would be able to see which order the stories would be refined and then could advocate if their story needed to be prioritized. During our prioritization meetings this meant the new stories that were added could be moved up to be refined sooner, but it did not mean that it would necessarily be ready by the next sprint.

The lines made it easy for everyone to understand. If the story they want worked on was below the line then it was not ready and it would have to be prioritized under the PO refinement line. When new stories were added, they were added to the bottom but could be moved up to the top of the PO refinement as long as there was agreement among the stakeholders. Even if there was total agreement, it could not be moved higher than that unless it was approved by the development team. The lines were so simple, yet they were and still are one of the most important techniques that I use to keep my backlog organized.