About the author
Vinko Borčić
Project Manager and Product Owner
Whether you’re creating a grocery list or structuring a Scrum team’s backlog, good old checklists keep us productive and on track.
In Scrum, for sprint goals, it’s S.M.A.R.T.; for user stories, it’s I.N.V.E.S.T., and for Product Backlog, it’s D.E.E.P.
In this article, we describe how we keep our Scrum teams agile, focused, and aligned while delivering maximum value to customers by maintaining an Improvement Backlog that effectively guides work and adapts to the ever-changing landscape of product development.
D.E.E.P. thinking
Roman Pichler and Mike Cohn coined the acronym D.E.E.P. The acronym encapsulates the essential qualities of a well-crafted Product Backlog, guiding Scrum teams in their quest to deliver value.
At its core, D.E.E.P. embodies the principles of continuous improvement through regular inspection and adaptation, underpinned by maximum transparency – the triad that forms the foundation of a Scrum team’s success.
In practice, a D.E.E.P. Product Backlog becomes a living artifact that reflects the Product Owner’s latest strategic thinking. High-value Product Backlog Items (PBIs) naturally gravitate towards the top, while those with lower priority, larger scope, or less definition settle at the bottom. This dynamic prioritization ensures that the team’s focus remains aligned with the most current business needs and market demands.
D.E.E.P. Acronym Meaning
- Detailed Appropriately:
The ‘Detailed Appropriately’ aspect of D.E.E.P. is crucial for the development team’s confidence and efficiency. It requires that PBIs ready for imminent work are fleshed out with sufficient detail to enable smooth execution. This doesn’t mean over-specification but rather striking a balance between clarity and flexibility. - Estimated
Estimation, while sometimes controversial (as evidenced by the #noestimates movement), is vital in maintaining a D.E.E.P. Product Backlog. Whether using story points, ideal days, or other metrics, these estimates provide a ballpark understanding of the complexity and effort involved in each PBI. This information is invaluable for sprint planning and managing stakeholder expectations. - Emergent
The emergent nature of the Product Backlog is perhaps its most dynamic characteristic. It’s in constant flux, responding to new information, market changes, and evolving priorities. This fluidity allows for the addition, removal, and reprioritization of items. - Prioritized
The ‘Prioritized’ aspect of D.E.E.P. ensures the Product Backlog reflects the relative importance of each item. With the most critical and valuable items at the top, this ongoing process requires the Product Owner to continually reassess and reorder items based on changing needs and market conditions.
Effective prioritization helps the team focus on what matters most, reduces waste, and increases the likelihood of delivering a product that meets stakeholder expectations. It also facilitates more efficient sprint planning, as the development team can easily identify which items to pull into upcoming sprints.
The Improvement Backlog
Two backlog types are used in Scrum: Product and Sprint Backlogs. A third one isn’t required but, in our experience, proved to be very helpful: Improvement Backlog.
The D.E.E.P. principle can be applied to Improvement Backlog as well.
Improvement Backlog is a list of all the items that come up during Sprint Retrospectives or Overall (conducted on the organization level with management) Retrospectives.
One way to do a Sprint Retrospective would be:
- Scrum Master chooses one of the Retrospective formats. Switching is encouraged to keep these events fresh, but you can’t go wrong with a trusty Start-Stop-Continue format for starters.
- The Scrum Team sits together and gets around 5 minutes to fill the board (either physical or virtual) with post-its, each containing proposed improvements (e.g., handling technical debt, better team communication, better-defined business requirements, etc.).
- Scrum Master will ask the team members to elaborate on their post-it, discuss the action steps needed to improve it, write notes down and then continue with the next post-it.
- Near the end of the session, the Scrum Master will ask the team to vote to pick priorities from all of the mentioned impediments. The classic and effective way to do this is with dot voting. Team members get several dots, which they can place on one or different post-its. The most dots = highest priority improvement that should be tackled as soon as possible.
- After the Retrospective ends, Scrum Master will add everything to their task management app and form an Improvement Backlog.
To ensure improvements don’t just remain as good intentions, integrate them into your Sprint Planning. Consider adding improvement tasks to your Sprint Backlog before bringing in new features. This approach allows the team to commit to both product development and process improvement, making continuous enhancement an integral part of your workflow rather than a separate, often neglected plan.
D.E.E.P. Product Backlog Characteristics in Improvement Backlog
If we treat Improvement Backlog in the same fashion we treat Product Backlog, D.E.E.P. principles should be applied as well:
- Detailed appropriately – to inspect and adapt our process, every impediment has to be detailed and well explained as it’s crucial for the next thing, which are the actual action steps to make progress.
- Estimated – it’s quite helpful to have at least a rough estimate. T-shirt sizes work well for this, especially if it’s an Overall Retrospective which usually handles impediments on the organization level.
- Emergent – similar to Product Backlog, Improvement Backlog is evolving after each Retrospective – items are added, removed and reprioritized.
- Prioritized – the team votes on the next priorities and chooses what to tackle first. If there are several similar items, the Scrum Master and Product Owner can always employ similar prioritization techniques as with the Product Backlog (i.e. value/effort matrix, etc.).
Nurturing Team Growth through Gradual Improvement
The essence of agile methodology lies in the ability to adapt and improve over time. This principle extends beyond product development to encompass team dynamics and processes.
The Improvement Backlog serves as a tool for this ongoing evolution, offering a structured approach to addressing challenges and seizing opportunities for team growth.
In practice, the Improvement Backlog becomes a record of the team’s commitment to improving. It captures insights from Retrospectives and team discussions, turning them into actionable items. This process enhances the team’s performance and encourages open communication and shared responsibility.
For example, if team members notice recurring issues with knowledge sharing, they might add an item to the Improvement Backlog focused on occasional cross-training sessions. This could involve periodic pair programming exercises or skill-sharing workshops, aimed at broadening team members’ expertise across different areas of the project.
Using the Improvement Backlog in Team Retrospectives
The value of the Improvement Backlog lies in its ability to guide meaningful change over time. By giving it similar attention to the Product Backlog, teams can ensure that process improvements get the focus they deserve. This approach involves periodic review sessions during Retrospectives where the team collectively looks at, refines, and prioritizes improvement items.
During these Retrospectives, the team might find that some improvements are irrelevant or that new, more important issues have come up. The ability to adjust priorities ensures that the team’s efforts always align with their current needs and goals. For instance, an item about improving code review processes might be reprioritized if the team starts facing challenges with testing procedures.
Additionally, the Improvement Backlog serves as a record of the team’s journey. By occasionally reviewing completed improvements during Retrospectives, teams can acknowledge their progress and understand how they’ve evolved. This reflective view can be valuable for spotting long-term trends in team performance and collaboration.
Incorporating Continous Improvement into Team Workflows
To make continuous improvement a natural part of the team’s routine, it’s helpful to integrate it into existing activities. This integration can take various forms:
- Sprint Planning:
Consider allocating a small portion of each sprint to work on items from the Improvement Backlog, allowing the team to address process issues alongside product development. - Retrospectives:
Use part of each Retrospective to review and update the Improvement Backlog, ensuring it remains relevant and actionable. During these sessions, dedicate time to discuss ongoing improvement initiatives and their impact. This allows the team to reflect on the progress of their improvement efforts, share insights, and make adjustments as needed. By incorporating this discussion into regular Retrospectives, teams can maintain a consistent focus on improvement without the need for additional meetings.
By weaving improvement efforts into these regular team activities, the Scrum team creates a sustainable approach to enhancing their processes and collaboration.
Improvement Backlog = better efficiency and collaboration
The journey of gradual improvement, supported by a well-maintained Improvement Backlog, helps Scrum teams embody agile principles more fully. It creates an environment where team members feel empowered to contribute to the team’s evolution, leading to better collaboration and efficiency over time. As teams progress on this path, they often find that their ability to adapt and innovate grows, allowing them to handle challenges more effectively and work together more smoothly.
By applying D.E.E.P. principles to their Improvement Backlog and making it a regular part of their Retrospectives and team practices, Scrum teams can create a sustainable approach to ongoing growth and development. This not only enhances their ability to deliver value through their product but also fosters a more satisfying team environment where continuous improvement becomes a natural part of how they work.
We helped many with agile transformations! They improved how their products are built and how their software development teams function. If you want to learn more from our Scrum Masters and Product Owners, contact us and let’s bring your ideas to life.
