An understanding of the Agile Product Backlog Grooming “Iceberg” is important. A typical Agile approach of Product Backlog grooming is sometimes focused primarily on limiting the backlog to only about 2-3 sprints ahead and doing grooming only as needed to get stories ready for development. That is a big difference between a “pure” Agile approach and more of a hybrid approach that blends an Agile development approach within a somewhat plan-driven envelope. If your project can be totally adaptive and doesn’t require a plan, you can probably live with that approach and completely define the Product Backlog “on the fly” as the project progresses. However, in many situations (particularly in large enterprise-level projects), there is a need to have a plan (either at the release level or project level) for the project. It’s very difficult, if not impossible, to limit the backlog too much and also be able to have some kind of plan of where the project is going.
For that kind of environment, I like the idea of thinking of the Product Backlog as an “iceberg” as shown in the diagram below (I believe this iceberg Idea was originally created by Mike Cohn):
The “iceberg” idea is that as you pull items off of the top of the iceberg, other stories that are at lower levels in the iceberg move up to take their place. The process of developing stories and moving them up the iceberg goes on continuously to feed the development process. A Kanban process with different stages of definition for stories fits this process very well. (Thank you to Michael Hurst for suggesting that) Here are a couple of suggested guidelines for this process:
- You never want the development team waiting for stories to go into development. The number of stories that are fully groomed and ready to go into development should always be far enough in advance to keep the queue from going empty and to prevent developers becoming idle waiting for stories to develop.
- There are logical stages that the grooming process for the rest of the backlog goes through and those stages should align with whatever planning objectives you need to meet. For example, if there is a need for release-level planning or project-level planning to forecast a plan and an estimated schedule, the Backlog needs to be sufficiently-defined and defined far-enough in advance to support that objective.
- Product Backlog grooming can be a very time-consuming process and the time for grooming of what’s coming next needs to be built into the current sprint or it may not get done in time to keep up with the development effort.
- Using people on the team efficiently to do backlog grooming can be a challenge. The developers who are going to take responsibility for the development of the stories need to be involved in the final stages of grooming prior to taking the stories into development so that there is a common understanding of the intent for the stories. However, it might be a significant drain on the team if the entire development team became deeply engaged in the very early stages of backlog grooming – a large portion of that effort can be done by the Product Owner and/or a Business Analyst working with the Product Owner supplemented by inputs from the development team as needed.
What is Agile functional decomposition? (and why is it important?) Investopedia defines “functional decomposition” as follows:
“A method of business analysis that dissects a complex business process to show its individual elements. Functional decomposition is used to facilitate the understanding and management of large and/or complex processes and can be used to help solve problems…Basically, functional decomposition takes something complicated and simplifies it. The individual elements of the process and their hierarchical relationship to each other are commonly displayed in a diagram called a functional decomposition diagram.”
Why is that relevant to Agile? Agile is about maximizing the business value that a project produces. On small, simple projects, you might be able to discover what that business value is easily based on direct face-to-face discussion with the Product Owner and individual stakeholders. On large enterprise-level projects, that may not be so easy to do. As an example, I was involved in a large project with about 500 user stories and we had to do some prioritization to move things out to a future release. It’s very difficult to do that on a project of that size without understanding the relationships among the stories if they’re not organized into some kind of functional hierarchy.
Using Agile functional decomposition to organize stories into epics and themes makes it possible to keep all of the stories well-aligned with producing the higher-level business value that the project is intended to produce and makes it a lot easier to effectively manage the Product Backlog. It also provides a capability for traceability – you can look at the top-level functionality and then look down into the functional decomposition to verify that the lower-level functionality is really complete and sufficient to support the higher-level functionality.
Functional decomposition has been around for years but many people don’t think it is relevant to Agile projects – it’s one of those traditional, plan-driven practices that many people seem to assume is now obsolete and no longer relevant with Agile, but I don’t believe that is the case. You don’t have to completely throw away all the traditional plan-driven practices you may have learned in order to practice Agile and some of those practices become especially important as you begin to try to scale Agile to an enterprise level…Functional Decomposition is an example.
The role of a Business Analyst in an Agile project is not well-defined just as there is no defined role for a Project Manager on an Agile project. On small, simple Agile projects there may not be a need for either of these two roles but that is frequently not the case on large, complex enterprise-level projects.
The role of a BA is often neglected – it is assumed that the Product Owner plays that role but it can be difficult for a Product Owner to perform that role without some assistance on very large complex projects. I recently had to create a job description for hiring a BA on an agile project – here’s what I came up with as the primary skills needed:
- Analyzing a broadly-defined area and using functional decomposition to define high-level epics and stories to create a well-organized, value-driven framework to provide the required business value in the Product Backlog.If the stories and epics follow a logical functional hierarchy it provides a mechanism for better understanding the relationship of the stories and epics to each other and for satisfying overall business goals.
- Writing individual stories that are very clear and concise and are easy to understand and implement by the development team.Writing effective user stories is a skill that is often taken for granted. What is often overlooked in good stories is the “why” or the “so that” clause that expresses the business value the story is intended to provide. A good BA can provide that perspective that is difficult for a developer to provide.
- Identifying related user stories and epics, grouping them into themes as necessary and documenting the interrelationship and associated business process flows as necessary.The interrelationship of user stories and epics should be well-understood and the implementation of stories across different functional areas may require some planning and coordination so that they are consistently implemented. This overall framework can provide a mechanism for easily identifying any inconsistencies and/or missing functionality.
- On large projects, there may be a need to integrate the needs of related projects as well as the needs of a number of different stakeholders to produce an overall solution.
The key point is that if a Business Analyst is involved at all in an Agile project, he/she should add value in some way and should not be just an intermediary between the development team and the business users and stakeholders.
Questions frequently come up about “What’s the Right Level of Detail to Put in an Agile User Story?” – I want to share some thoughts with you on that subject:
There is no absolute right/wrong answer about how much detail a story should contain – the best answer is “it depends”. The level of detail in the story depends on a number of factors including:
- The complexity and nature of the story itself
- The level of interaction available from the Product Owner to explain what is required
- Where the story is in the overall lifecycle – there are at least three levels of detail required depending on how you plan projects, releases, and sprints:
- Project-level Planning – Least detailed, suitable for very high-level project planning
- Release-level Planning – medium detail, enough detail to do story point estimates
- Sprint-level Planning – most detail, suitable for actually starting development and planning development tasks
Here’s what I recommend as some guidelines:
- It is always best to err on the side of less detail rather than more detail as a starting point – Agile has a concept of “Just Barely Good Enough” which means you put a sufficient level of effort into the task to accomplish what is needed and nothing more – anything more than that is waste
- Use a top-down, functional decomposition approach to progressively elaborate the level of detail in stories:
- Start at the top-level to identify epics and story titles only
- Once that is done and approved, write the actual stories, but only to the level of detail required
- Rely on the developers and others on the team (QA) to tell you when the story is good enough – a lot of collaboration and face-to-face communication is essential – we need to get away from the Waterfall approach where a BA writes detailed requirements (stories) and then hands those requirements off to developers
Again, the key thing I want to emphasize is that there is no right/wrong answer about how much detail a story should contain…some general guidelines and models can be developed to guide the effort, but the real test of whether a story is well-written or not is based on feedback from the people who have to use the information in the story for whatever purpose it is intended for (estimation or development).