Category Archives: Agile Requirements

Agile Product Backlog Grooming “Iceberg”

An understanding of the Agile Product Backlog Grooming “Iceberg” is important.

How Far Do You Need to Plan Ahead?

A key decision is “How far do you need to plan ahead to stay ahead of the development process?”

  • A typical Agile approach of Product Backlog grooming is sometimes focused primarily on limiting the backlog to only about 2-3 sprints ahead
  • That approach involves only doing grooming only as needed to get stories ready for development

There can be a big difference in the Product Backlog Grooming depending on what level of planning the project requires:

Totally Adaptive Approach

If your project can be totally adaptive and doesn’t require a plan, you can probably live with that approach. You could completely define the Product Backlog “on the fly” as the project progresses.

More Plan-driven Approach

However, in many situations there is a need to have a plan either at the release level or project level for the project. In that situation, it’s very difficult, if not impossible, to

  • Limit the definition of the backlog too much and
  • Also be able to have some kind of plan of where the project is going

The Product Backlog Grooming “Iceberg” Approach

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):

Product Backlot Grooming Iceberg

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.

Product Backlog Grooming Guidelines

Here are a couple of suggested guidelines for this process:

1. 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. You always want to prevent developers becoming idle waiting for stories to develop.

2. Logical Stages for the Grooming Process

There are logical stages that the grooming process for the rest of the backlog goes through. 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 far-enough in advance to support that objective.

3. Product Backlog Grooming Can Be a Very Time-Consuming

Product Backlog grooming can be a very time-consuming process. 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.

4. Using People on the Team Efficiently

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, there should be 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

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What is Agile Functional Decomposition? Why Is It Important?

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 facilitates 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.”

How Is It Relevant to Agile?

Why is that relevant to Agile? A major goal of Agile is to maximize the business value that a project produces.

  • On small, simple projects, you might be able to easily discover what the business value is 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:
    • An example is that 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
    • Doing that on a project of that size without understanding the relationships among the stories can be very difficult if they’re not organized into some kind of functional hierarchy

Keeping Stories Well-Organized

Using 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
  • It makes it a lot easier to effectively manage the Product Backlog

It also provides a capability for trace-ability

  • 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
  • That the lower-level functionality is sufficient to support the higher-level functionality.

Overall Summary

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 people seem to assume is now obsolete and no longer relevant with Agile. 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

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What is an Agile Business Analyst? How is the Role Different?

Many software development projects are moving rapidly to an Agile development approach. That has dramatically impacted the role of a project manager in an Agile environment.  Agile also has a significant impact on the role of a Business Analyst.  In this article, we will explore “What is an Agile Business Analyst?” and “How is the role different?”.

What is an Agile Business Analyst?

Traditional Business Analyst Role

The traditional role of a Business Analyst is defined as follows:

“The business analyst’s primary objective is helping businesses implement technology solutions in a cost-effective way by determining the requirements of a project or program, and communicating them clearly to stakeholders, facilitators and partners.” Business Analyst Job Description, Villanova Univ.

That’s the predominant role that has been played by Business Analysts for many years.  In some cases, the role has boiled down to simply talking to users about what their needs are and writing requirements documents.

  • That it has been a very documentation-intensive role. 
  • However, the real value-added that a Business Analyst should provide is in helping to define innovative solutions to business problems.
  • It should not be limited to just simply creating requirements documents. 

In a traditional plan-driven environment, documentation often takes on a life of its own. In that environment, it is easy to lose sight of the fact that the goal is to create business value and documentation is only a by-product.

What Are the Skills Needed by a Business Analyst?

For a Business Analyst to really provide value beyond simply writing requirements documents, the Business Analyst has to have an understanding of:

Knowlege AreaRequirement
Business Domain KnowledgeIn-depth knowledge of the Business Domain that they work in (finance, healthcare, manufacturing, or whatever else it might be). That means that the BA understands:
  • What the major business processes are,
  • The metrics that are important to the business, and
  • How to improve the processes from a business perspective
Process Improvement Tools and TechniquesBusiness Analysts need to understand how to:
  • How to use process improvement tools and techniques such as Six Sigma and others to analyze an existing business process, and
  • Identify and define opportunities for improvement
IT Solutions perspectiveNeed to know how to translate that understanding of the business process improvement needs into IT solution requirements to create effective and innovative business solutions
Project Process UnderstandingFinally, they need to understand:
  • How an overall project development process works, and
  • How their role fits into that process so that they can work most effectively as a member of a development team

These fundamental skills have not changed over the years and a good Business Analyst is strong in all of these areas. However, in some cases the role of a BA has degenerated into simply writing requirements documents.

What Is Wrong With the Traditional Business Analyst Role?

The problems with the Traditional Business Analyst role are essentially the same as a Traditional Project Management role.

Level of Uncertainty

In today’s environment, there is a much higher level of uncertainty associated with defining software solutions.  The traditional approach of documenting detailed requirements prior to the start of projects just doesn’t work well with high levels of uncertainty. 

  • The Business Analyst might wind up wasting a lot of time trying to define detailed requirements prior to the start of the project
  • Many of those requirements might be based on speculation and assumptions, and
  • Those requirements might then go through an enormous amount of change as the project is in progress.

Emphasis on Creativity and Innovation

The emphasis in many projects is shifting:

  • In the past, the primary emphasis in many projects has been on planning and control to achieve predictability of project costs and schedules
  • Competitive pressures today have created a need to put more emphasis on creativity and innovation to maximize the business value of the solution

An over-emphasis on planning and control can destroy creativity and innovation.  Can you imagine trying to develop the next generation of a very innovative product like a new iPhone using a traditional, plan-driven approach? It would be impossible to do that based on developing detailed requirements for the product upfront.

How Do Agile Requirements Work?

To understand the role of a Business Analyst in an Agile environment, we first need to understand how an Agile requirements process works. 

  • There are a lot of misconceptions about Agile – Some people may think that there are no documented requirements and the project is started by the developers writing code.   
  • That is not the case – The approach for developing requirements in an Agile project should be directly related to the level of uncertainty in the project

High Levels of Uncertainty

In a project with a high level of uncertainty, it would be foolish to try to develop detailed requirements prior to the start of the project.

  • In that environment, the requirements might be limited to an overall vision and high-level requirements that the project must meet. 
  • More detailed requirements would be further elaborated as the project is in progress. That elaboration would be based on direct feedback and inputs from the users

Lower Level of Uncertainty

If there is a lower level of uncertainty, the project might go further towards developing more defined requirements.

  • That might be particularly true if there is a need for some level of predictability of the project costs and schedule
  • However, an Agile environment would still emphasize some level of flexibility and adaptivity to maximize the business value of the solution as the project is in progress

Key Differences

There are several key differences in an Agile approach:

1. Less Emphasis on Documentation

Agile requirements are considerably simplified and are typically written in terms of “user stories”. 

  • A “user story” is a brief and very succinct definition of a business need. It does not provide any detail about how it will be implemented, 
  • A “user story” is considered to be a “placeholder for conversation”. Further definition of how it will be implemented will be determined based on direct, face-to-face communications with the users. That will take place as the user stories are being implemented.

2. Changes Are Encouraged

An Agile approach is designed around flexibility and adaptivity to maximize the value of the solution.  For that reason, changes to requirements as the project is in progress are encouraged.

3. Direct Communication

There is a lot more direct communication between the business users and the project team. 

  • First, there is a Product Owner who represents the business. The Product Owner directly participates in the project to provide overall business direction and priorities
  • Second, the developers on the project team are expected to communicate directly with the business users to further elaborate and define requirements

In this kind of environment,

  • It should be obvious that the role of a Business Analyst should be more than just a “middle-man” to talk to the users and document requirements
  • That role would inhibit direct communications with the project team. It would probably also limit the flexibility and adaptivity that is so important to an Agile approach

So, What is an Agile Business Analyst?

So, What is an Agile Business Analyst?

  • The role of a Business Analyst in an Agile environment is not well-defined just as there is no defined role for a Project Manager at a team-level in an Agile environment
  • 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

In an Agile environment,

  • It might be assumed that the Product Owner plays the role that might normally be played by a Business Analyst. However, the Product Owner responsibility goes well beyond the role of a Business Analyst, and
  • It can be very difficult for a Product Owner to perform that role without some assistance on very large complex projects

Ways to Provide More Value-Added

In any case, the value-added provided by a Business Analyst in an Agile environment needs to go beyond simply writing requirements documents.  Here are some potential ways that a BA can provide a higher level of value.

1. Process Improvement

Many times, simply automating a process “as-is” does not provide a sufficient level of value.  Rather than simply documenting a process “as-is”, a Business Analyst can provide a much higher level of value by finding innovative ways to improve an existing process to make it more efficient or more effective.

2. Analyzing a Broadly-Defined Area

Large, complex projects may require:

  • 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.

3. Writing Individual Stories

A Business Analyst can provide value by writing user 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.

4. Identifying Related User Stories and Epics

In a large complex project, there is also value in grouping stories into themes and epics 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.

5. Integration With Related Projects

On large projects, there may also 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.

Overall Summary

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. He/she should not be just an intermediary between the development team and the business users and stakeholders.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What’s the Right Level of Detail to Put in an Agile User Story?

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”.

What Factors Effect the Level of Detail?

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 PlanningLeast detailed, suitable for very high-level project planning
Release-level PlanningMedium detail, enough detail to do story point estimates
Sprint-level PlanningMost detail, suitable for actually starting development and planning development tasks

Some Recommended Guidelines

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

Overall Summary

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).

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Blending Agile and Traditional Project Management