A well-defined and continually evolving backlog is crucial for developing a rock-solid product that truly meets customer needs. DEEP is an acronym for backlog characteristics, that was coined by Roman Pichler around 2005/06. DEEP stands for:
- Detailed Appropriately (items are detailed just enough for the time they will be worked on)
- Estimated (items are roughly sized)
- Emergent (the backlog evolves as more is learned)
- Prioritized (items are ordered based on business value, risk, etc.)
Looking at these characteristics helps one have a well refined backlog. (There are other ways to look at the backlog/backlog items – INVEST, Ready, DoR, SMART backlog).
The situation at a “well-funded” start-up:
A well-funded start-up with the motto for their product development being “Built Ahead, Built to Lead” was facing challenges in getting their product out of the door. There were four functional teams working on the product and they faced many challenges.
- Lack of Shared Understanding: The four teams were not aligned on what needs to be built and why. They knew the overall vision for the product and for the function. Often more focus was on their functional part, at times leaving the dependent teams blocked by ignoring their needs.
- Inconsistent Maturity: Two of the teams were home grown and couple teams came in thru an acquisition. There were varying backlog practices across teams and that was slowing down the collaboration. There were features in the backlog, couple teams were breaking them down into stories and tasks and others were creating tasks directly under the feature. Different levels of granularity made dependency management difficult.
- Vague and Incomplete Requirements: Teams would start development without clarity, by their eagerness to be the leaders. The product manager was a visionary, who would paint a wonderous picture by outlining broad requirements but with critical details missing. The excited team would jump into making it happen.
- Execution Readiness Gaps: At the time of the PI/Sprint Planning the Backlogs would not be ready for sprint or iteration planning. This was due to including the hot new features into the backlog and varying levels of team maturity.
- Scope Creep: Often new work was added mid-iteration without assessing impacts, a great deal of it was due to incomplete requirements and to some extent due to poor detailing and breakdown of the work.
- Unclear Prioritization: Teams were struggling to focus on what delivers the most value, as along with Product Managers; Sales Leads and Functional heads would come up with new ideas and needs.
The need
The above pattern is common and repeats across organizations with some variations. The need here was to help teams improve backlog management, ensure delivery readiness, and align backlog items with strategic value. To ensure that vague and scattered requirements are transformed into structured, value-driven backlogs.
This required using guidelines like DEEP to arrive at a good backlog. Along with this the level of collaboration between the stakeholders – Product Manager, Product Owners, Engineering Head, Functional Leads, Tech Leads and Teams; had to be enhanced and sustained.
The solution:
We could help the organization with a workshop covering all aspects of backlog management, followed by bringing in changes in their approach to the backlog refinement, with our mentoring and coaching.
Set up the Release goal
One of the challenges was that inputs were coming from many stakeholders, all seemed valid and of immediate interest. The key stakeholder’s Product Manager, Engineering Head and Sales Head collaborated to define what should the Release goal be for the subsequent and adjacent releases. It was not something cast in stone, changes could be incorporated if needed, but would need a review of the plans and consensus to make changes. All agreed that these changes would be recorded to help understand the changing needs and how they can be managed better going forward.
The Product Manager was made accountable for the Release goal. This was a shift from the diffused accountability of the initial days, which had worked well when they were a smaller team.
Refining and sizing the features
The teams worked upon a template for the feature which would capture all the details, including acceptance criteria, dependencies, and risks. The template used by various teams were collated into a single template, reviewed, and enhanced/updated.
The feature sizing was done using T-shirt sizes, with participation of all the leads. For some features all were not able to contribute on the sizing, but were able to get an understanding of the features. This exercise helped immensely with surfacing of the dependencies and risks. One of the changes here was involving all the team leads that helped improving alignment and collaboration across the teams.
Breaking down the Features into stories
This was not being done uniformly across all teams. The teams were educated and coached/mentored for creating good user stories. The INVEST criteria was used, which helped ensure that the stories were well defined and delivered value to the customer.
The breaking down was being done with just the Engineering Leads and Team; Product Owners were included in the process. PO’s participation helped the team avoid making assumptions, by providing required information/details. This also helped surface items where more information was to be gathered by the PO.
This step culminated by looking at all the stories in a feature and ensuring that the stories would indeed achieve all that the feature was set out to do. The key change here was improved collaboration between PO and the Team for fleshing out the feature.
Refining and sizing the stories
The stories were now better than in the past due to the involvement of the PO in the feature break down. It also helped the team arrive at a common understanding of the story with participation from all.
The concept of relative sizing was refreshed with the team. The sizing was done using planning poker and story points. The story and the acceptance criteria were read out, if it lacked clarity and the team was unable to size it, it was set aside for additional discussion with the PO. The team arrived at the size in two rounds for most of the stories.
The very act of each team member telling a size for the story, followed by sharing the thought behind that number helped elicit and surface all inputs and questions from all the team. This helped with and inclusion of any missing details in the story and have a common understanding of the story.
This step culminated in the stories meeting their “Definition of Ready”. The key change here was participation of all the team members and reaching out to the PO for missing information.
With this the team was all set with a backlog that met the DoR.
The journey to this state was ensued with participation and contribution from key stakeholders. There was marked improvement in the collaboration and alignment across the organization.
While this was one approach that brought significant improvements, every organization’s context is unique. I’d love to hear how you’ve tackled backlog challenges in your team.
