Posted by Product Tree is a tool that helps you prioritize your product backlog. It provides a visualization of all the inter-related features in your product. The Product Tree is usually present as a bottom-up process, where user stories are ordered by their business value and risk level.
When building the product tree for our clients, we use expert knowledge about their domain, industry. And users to order the stories according to their importance to the business. We also try to immerse ourselves into thinking like engineers who restricts the time, budget, and technology constraints. That’s why at Codemate we always question pruning is need at all.
The need for pruning emerges when you have too many story variants that do not fit well together after you’ve grouped them into epics and features. It can also happen that one epic has a lot of very similar stories that need to be spread out over several epics.
In the image: The product tree consists of epics and features, which places vertically on the basis of their business value. To prevent “emergent complexity”, we discard those stories which do not fit well together so as to create smaller chunks for development.
This process cannot be done without trying the ideas first in practice. That’s why it’s important that your backlog is kept up-to-date, flexible. And easily accessible by all stakeholders – including developers who use it as a day-to-day work tool.
The four most common mistakes when a product tree:
-
Is Decoupled from the Process
If sprint planning and backlog grooming sessions happen in a vacuum. You’ll not notice problems regarding your product tree until it’s too late. It is vital to monitor how well epics fit together during those sprints so as to spot deviations early on. If you do not, your product will have an increased amount of “emergent complexity”. Where new features add without much thought because they seem interesting instead of adding value to the overall product. In this kind of environment, it’s easy for random ideas – even bad ones – to get into production code. This results in messy code that is costly to maintain.
-
Has No Framework
Without clear rules on how features placed in the tree, it is difficult to enforce a methodology that sticks. The first iteration of a product could end up with an epic having hundreds of tasks in the Product Backlog. Which would clearly be an indicator that something’s wrong. However, until they establish frameworks for breaking epics into tasks. And prioritizing them by impact/effort or user stories. This mistake can easily happen again during future iterations.
-
Lacks Role Management
If your company lacks in defining the roles (e.g., Product Owner), there’s no clear way to assign accountability. When it comes to maintaining the product backlog. And prioritizing features strategically. Without someone task with ownership over maximizing value delivery. You will find yourself making simple yet important decisions like what needs to be built based on more of an ad-hoc basis.
-
No Process for Adding or Removing Items from the Product Backlog
We all know that the product backlog is never set in stone—it needs to be changed frequently, even during iterations. However, if there are no explicit rules for when items get add or remove then you will find yourself wasting time re-prioritizing current epics instead of focusing on new requirements that need attention. This also means that your backlog isn’t dynamic enough and will take too much time/effort to change in order to accommodate shifting priorities and market conditions (e.g., outages).
Thus, we end up with a process like this:
1) add item
2) complete it
3) remove it from the backlog.
The way suggests optimize this is to schedule sprints where you focus only on adding new items, prior to or post-release date (more on that later). Treating these “adding sprints” like other usual iterations would be beneficial because all planning activities (e.g., refining user stories, sizing epics, estimating tasks, creating tasks) are already there and ready to use.
Now let’s see how we can set up an adding sprint:
1) Prior to starting your adding sprint session, gather stakeholders together via a conference call or email/chat beforehand so they can give you their desired requirements for upcoming enhancements/additions. Review all user stories to ensure that you are not missing anything before the stakeholder meeting(s).
Also Read: animefrenzy
2) During your session, take each user story in turn and ask stakeholders. If there are any additional requirements they may have before you begin work on implementing these new features/enhancements. This is an excellent time to refine stories so that they may be better prioritized against other items, or at least get their business value for future development. At the end of each adding sprint session, it recommends that you create a release burn-up chart (or at least review one already creat by QA team members).