In this series of five posts, I’d like to talk about getting requirements right and delivering them faster. My goal is to provide you with new techniques and approaches for producing high quality requirements on your projects.

If you’ve taken our free email course called Getting Requirements Right - this series of posts covers the same ground. We’ve now put up a new free course which you may be interested in: BABOK 3 Navigation Maps.

I’ve been doing business analysis for a wide variety of projects over the last twenty years. I’ve encountered tight deadlines, difficult compliance requirements and conflicting stakeholders.

All the while, I have been selecting BA techniques and approaches enabling me to complete the projects successfully.

I would like to share them with you in a concise and actionable way in these posts.

Overview

One of the significant changes in BABOK 3.0 is that it merges the Agile Extension into the main body of business analysis knowledge. The idea is that a BA should use multiple techniques available from different methodologies - both Agile and non-Agile to deliver higher value in a shorter time.

The Agile approach offers the following core tools for the purpose of defining requirements:

  • Epic Stories
  • User Stories

The traditional approach recommends

  • Use Cases
  • Process Design.

These tools are used at different stages of the project. We will consider each of them in turn.

We will walk through ways of capturing requirements using user stories, use cases, identifying requirements types, use templates for documenting the captured requirements, and a way to handle process design in an effective manner.

Where do you start?

When starting a new project, your first task is to learn about a new project as much as you can. Define together with the project manager (PM) what deliverables he or she expects from you and by when. These deliverables define scope of BA activities.

Your second task is to specify what and in which form you will deliver. If you use the Agile approach, it could be an Epic Story coupled with User Stories, or Use Cases based on the User Stories, or a full-blown requirements document. It is up to you to negotiate with the PM what is required in your case.

Your third task is to specify and agree with the PM what a “good enough” state of your deliverables would look like. Depending on the project nature, you may need more or less formal deliverables, and more or less detail. By doing so, you’ll be able to set the right expectations with your project team. You will also start to feel comfortable about your workload and estimated timeline. It is very important where you handle a few projects simultaneously.

Finally, communicate the agreed terms to the involved stakeholders and keep them engaged all along your specified timeline.

Outputs of BA activities

Regardless of the portion of the path you’ve committed to, keep in mind the key deliverables:

  • Business requirements
  • Functional requirements
  • Non-functional requirements
  • Transition requirements.

Existing business processes will almost certainly require changes, so work on:

  • Current processes and their pain points
  • Desired Process changes
  • Communication of the process changes
  • Affected users and their training needs.

Things to keep in mind

Always write a high level overview of the desired solution. Writing the overview will help you to formulate the project objectives. It will also help you to communicate with the stakeholders in a confident manner. The overview gives you important information about the project:

  • Business context
  • Solution scope
  • Required solution capabilities
  • Level of solution complexity.

TIP: Use the overview as your communication vehicle in collaboration activities with all your stakeholders.

Maintain your relationship with stakeholders - the current assignment is probably not the last time you are going to work with them! Tomorrow’s project might see you connecting with them once again.

Having an agreed and clearly defined scope of your BA work reduces uncertainty and makes you feel in control of the job ahead.

Agile angle

Let’s turn our attention to the Agile approach now, and have a look at it from the Waterfall perspective.

Epics, Themes and User Stories

Coming out of a comfortable and slowly moving Waterfall and jumping into an Agile stream could be a challenging exercise. Using Agile terms can be confusing at the start. You’ll need to distinguish terms such as:

  • Epics
  • Themes
  • User stories.

I thought it would be beneficial to explain Agile terms for those who are new to the approach. I would also like to bridge these two approaches to make your transition easy and smooth.

Epic

This Agile term is used to define either the full solution or a big component of the solution where finer details are not known upfront and left for the later stages to deliver. Typically, epics and themes are used in the startup phase of a project because they provide a very high level view of the required capabilities. Think about EPIC as an acronym, the definition of which is “Experience Path I (Role) Claim”.

This term aligns well with the High Level Requirements in the Waterfall approach. 

Example: Imagine we are building a digital way of interacting with a bank. I may say that the new banking solution will include a few features, the details of which I cannot specify right now. By saying “a digital interaction” and “the banking solution” I’m giving you certain clues about the future solution - a mobile or browser-based banking application. 

Theme

As the Agile approach defines it, a “theme” is just a collection of User Stories related to a common feature.

Example: I might say that the mobile banking application will include the following themes:  

  • Account Management  
  • Deposits  
  • Money Transfers  
  • Alerts 
  • Payments  
  • Find a Branch.  

These themes give you a clearer idea of what the User Stories inside these themes could be about. 

This term aligns with the Functional Areas in the Waterfall approach. 

User Story

A User Story describes the actual details of what a user wants to achieve, and therefore is commonly used in the initiation phase of a project. I would recommend thinking about User Stories as scenarios with well defined acceptance criteria at the end.  

Example: Continuing with the same application, I can say that the Deposits theme includes User Stories such as: 

  • Schedule deposits 
  • Report on deposit totals 
  • View transactions. 

This term aligns with the High Level (Light) Use Case in the Waterfall approach. We will discuss user stories in detail in the fourth part of this course.

In this post I’ve introduced parallels between Agile and Waterfall approaches to facilitate your “switching” between the two. Remember that epics, themes and user stories provide an increasingly detailed view of the required capabilities. 

In Part 2, we will talk about process design. Stay tuned.