Satisfying Stakeholders with Agile Requirements

Traditional approaches to detailed requirements documents are being modified to accommodate faster, more lightweight communication methods. Business analysts must adjust their work styles and deliverables to fit into project development life cycles and methods.

As part of the process, it is important to understand if agile requirements differ from plan-driven requirements.  It’s also good to know if a mind shift is required to develop successful requirements.

Agile Requirements

1. How Do Agile and Traditional Requirements Differ?
2. Shift in Mindset for Agile Requirements
3. Tips for Creating Successful Agile Requirements

How Do Agile and Traditional Requirements Differ?

Agile requirements are not as different as you would expect. In a traditional environment, BA’s create detailed requirements.  In an agile environment, the documentation becomes a lot less important.  Most of the tools and analysis techniques that BAs have in their tool kit are still valuable and applicable in agile.  In fact, having an assortment of different tools to analyze is powerful.

As analysts, it is important to be aware of how a product or service will be used. You must also know the environment the product is expected to function in. This understanding comes from doing the analysis. You can still use techniques like swim lanes, workflow documents and process models to define the value.  The difference with agile is those insights can be documented at a high level using general sketches or holding a workshop to define information on a whiteboard. The requirements documentation must be sufficient to create a shared understanding for team.

Shift in Mindset for Agile Requirements

In agile you still document your requirements, but you may document them differently using post it notes on a wall, or on a flip chart with a picture of the flip chart to share with others not in the room. In other words, think about the way you document requirements in more creative ways.  You want to retain the analytical and thinking processes, including elicitation, and collaboration.   Importantly, it is not about NO documentation, it’s about AVOIDING overly detailed documentation.

If you get push back on the level of documentation within your organization, consider asking questions as to why documentation is needed to ensure what you are producing serves the needs of the company and the project. This will help organizations let go of old habits and intentionally reduce the rigor in the requirements to bring value to the organization.

Tips for Creating Successful Agile Requirements

Here are some helpful tips to try as you document agile requirements.

1. Agile requirements don’t need to be perfect

The key to success is agile requirements and documentation should be barely sufficient.   Your requirements do not need to be perfect.  Do just enough to meet the need and create a shared understanding.  Force yourself to let go of perfectionism when it doesn’t add sufficient value. Remind yourself as you work, is this the best use of your time.  It will help you step back and evaluate key tasks and outputs to deliver value.

2. Understand the timing

In an agile environment, how do you deal with completed requirements at the last responsible moment?  This doesn’t mean procrastinate. What it really means is, if you define some things too early in the process, the requirements will have to change, requiring unnecessary rework.

For example, if you create detailed models of what the product will look like before you know exactly where each feature is going to fall in the release plan, you may have designed something that isn’t needed until the last release if ever. In that time, some elements will have likely changed. The idea of letting things fall into place at the last responsible moment is a great time saver.  In the meantime, you can still be creating smaller increments of value that the team can consume. Knowing what can benefit from waiting allows you to learn along the way and gain more information and perspective.

3. Define a process to document ideas

Have an organization system for future ideas.  It’s an excellent way to capture a thought that might not be ready to explore and develop.  If you have documented the idea or an important finding at the time, you can come back to it when it may be more appropriate or beneficial.  The other benefit is that you won’t have to start from scratch. One way to keep track of these ideas is to write them down on a future date in your calendar to keep the idea of top of mind.

4. Balancing the high level and the details

Knowing when to focus on the high level and when to get into the details is a constant challenge of a business analyst.  When working on an agile project, in the early stages when you are doing product visioning, you need to focus on a high level.

However, there are times when a topic will come up and you must let the team talk at a detailed level to make sure everyone is understanding the vision and goals in the same way.  An idea may surface, and the team needs to go deeper into the details to determine it if the idea should be a part of the vision.

Over the course of a project, you will cycle through guiding the team through the details and then back to the high level to align with the larger project vision and objectives.  Don’t be afraid to go deep when the team needs to so that everyone feels comfortable there is a plan that will work and a shared understanding of the product or service features.

5. Be nimble

In agile projects, analysis requires you to define work slightly ahead of the development team.  You need to be able to continuously get more detail about the business needs and desired requirements.  At the same time as you are working ahead, you need to be able to respond to a change in the current iteration to help the development team adjust and prioritize.

Developing agile requirements means you have to be open and nimble to keep the present iteration moving while planning for the next set of work.

Still Interested in Developing Effective Requirements?

To help you adjust your analysis practices to a more agile style, RMC offers a case study-based course teaching professionals working on agile teams to develop effective agile requirements.

Contact us about this two-day, virtual session to learn how you can become nimbler while continuing to satisfy stakeholder needs on your next project.

You can also listen to my podcast with Dave Saboe.

Sources:https://www.batimes.com/articles/agile-requirements-documentation-what-s-really-needed