Requirements in Agile Business Analysis

      No Comments on Requirements in Agile Business Analysis

Agile is very light on documentation as clearly mentioned in its manifesto, “Working software over comprehensive documentation.”

Hence, as BA our focus is to have just enough requirements to get the work done.

How were the requirements collected in the Waterfall method?

It was a lengthy process that took weeks or months and the output was a detailed document that was then given to the development team to just begin work. This was not a wrong approach. It worked! However, it was flawed. The primary drawbacks were that it resisted change and had too many unnecessary details.

How are the requirements collected in the Agile method?

It is a quick process in which we essentially need a list. It is a wish list of prioritized features (user stories) that we expect in our product (or project).

What are User Stories?

In Agile, a stakeholder need (i.e.requirement) is stated as a user story.

However, they are not complete requirements in themselves but they represent a feature that will be built into the product.

Important facets of a user story:

  • Clear – a simple description of the requirement
  • Attributed – stated from the perspective of the person that has the requirement
  • Prioritized – the value of the requirement should be explicitly visible

User Story format:

As a ____ (role / actor)

I want to ____ (requirement  /description of need)

So that ____  (value / rationale)

The above format succinctly captures the who, what and why of the organization’s need. It very tersely conveys the key information we need to have a meaningful conversation about how the feature will be developed.

We should know who the actor is so that we can more appropriately develop the product, based on our understanding of the user. If we don’t know who the actors are, we won’t be able to build features for them.

Capturing the rationale/value is important because:

  • They help in prioritizing the story
  • They aid in understanding the actor better
  • They help to better develop the feature

Example:

As a website visitors

I want to create an account with the web portal

So that I can access the premium content of the website

Is the above requirement complete to begin work? Definitely not! However, it is complete as a user story. The details of the story can be fetched later when the story will be developed. However, it is a perfect requirement and has enough details for a discussion.

The actual content of the user story like the acceptance criteria, test scenarios, splitting, visual-models, etc can be fleshed out when the actual work on the story begins. This way we keep the focus on the conversation instead of the unnecessary upfront technical details.

Agile values individuals and interactions over processes and tools and the follow-up conversation between the product owner and the team are where the real requirements come out.

User story format significance:

As a ____ [PO needs it for road mapping and prioritization. Team knows who is it being built for]

I want to ____ [Crux of the matter]

So that ____  [Necessary for prioritization and understanding of constraints, etc]

User Story tips:

  • Keep them simple and avoid the use of technical jargons
  • Keep them small so that they are easy to manage in sprints

 

What are Acceptance Criteria?

Acceptance criteria are:

Tests

The completed code is tested against the acceptance criteria and if it fails then its a defect to be fixed.

Part of “Definition of Done”

The criteria define when a user-story is complete.

Requirements

Acceptance criteria are the closest thing to a conventional requirement in the Agile world.

Documentation

Acceptance criteria are the details of a  requirements

Constraints

Before a developer starts work on a user story he/she looks at the constraints on the user story and they are the acceptance criteria

 

Typical Development Process in Agile

Developer

  • chooses a story from the sprint backlog
  • ensures he/she understands the story and if not they’ll be assisted by the BA to understand the story
  • writes a collection of unit tests based on the acceptance criteria (this is a common technique in an Agile environment known as Test-Driven Development (TDD))
  • writes the code
  • runs the test. If the test is passed the story is complete else they rework on the code until the test is passed.
  • moves to the next story

From the above steps it is clear that acceptance criteria are extremely important and the closest thing to a specification. They decide when a unit of code is complete.

Acceptance Criteria Formats:

Boolean Statement (True/False) 

  • e.g. Password must have at least one numeric character

“Make sure that..”: 

  • Colloquial variation of the Boolean statement e.g. Make sure that the password has at least one numeric character

Given-When-Then: 

  • A structured pseudocode way of documenting acceptance criteria and it also ends up being a Boolean statement.
  • Used in Behaviour Driven Development (BDD).
  • Given (Precondition(s)) When (Trigger/Event) Then (System Behaviour(s))
  • e.g. Given the username is filled When the password is entered Then the user can login into the system

Acceptance Criteria Examples:

User Story:

As a registered user I want to login into the system So that I can view my account

Acceptance Criteria:

  • The user should be able to enter the username
  • The user should be able to enter the password
  • The system should check if the user exists
  • If the user exists, the system should allow the user and the user’s account page should be shown
  • If the user does not exist, the system should show an error message with “You do not have an account. Please register.”

User story:

As a user, I want to use a search field to type a city, name, or street, so that I could find matching hotel options.

Acceptance criteria:

  • The search field is placed on the top bar
  • The search starts once the user clicks “Search”
  • The field contains a placeholder with a grey-colored text: “Where are you going?”
  • The placeholder disappears once the user starts typing
  • Search is performed if a user types in a city, hotel name, street, or all combined
  • Search is in English, French, German, and Ukrainian
  • The user can’t type more than 200 symbols
  • The search doesn’t support special symbols (characters). If the user has typed a special symbol, show the warning message: “Search input cannot contain  special symbols.”

 

Acceptance Criteria Example  (Given When Then) 

User Story: 

As a new user I want to be able to register an account So that I can access our products services

Acceptance criteria:

Registration page contains a form with the following fields

  • Email address
  • Password
  • Submit

The email field must contain a valid email address

The password field must contain at least one capital letter, lower case letter and number

Submitting the registration page form will create a new account

Scenario-Based Acceptance Criteria

Given I am an unregistered user When I navigate to the registration page Then there is an email input field

Given I am an unregistered user When I navigate to the registration page Then there is a password input field

Given I am an unregistered user When I navigate to the registration page Then there is name input field

Given I am an unregistered user When I navigate to the registration page And I enter an email address Then the email address must be valid

Given I am an unregistered user When I navigate to the registration page And I enter a password

 

What are Epics?

Sometimes the initial requirements are

  • Not concrete
  • Too high level
  • Vague.

It is difficult to implement them.

These high-level user stories are called epics in Agile.

Epics are too big user stories.

When can we call a user story too big?

  • A user story is too big to be delivered entirely in a sprint.
  • If a team can’t get 6-10 user stories of that particular size done in a sprint then it is an epic.
  • If a user story is composed of multiple smaller stories.
  • If a user story can be summed up in a one-word or two-word phrase.
  • If the development team collectively believes it is an epic then it is an epic.

The above indicators are subjective and with experience you will intuitively learn to identify an epic.

E.g.

As a website owner

I want a blogging functionality

So that we can get useful user-generated content

The above story is an epic because:

  • “Blogging functionality” is a two-word phrase ( this is a subjective discussion but in this example, it is a large vague functionality.
  • It can be further broken down into multiple stories e.g. Creating blog posts, Editing blog posts, Publishing blog posts, etc.
  • If the above tests were inconclusive then we can ask the scrum master and team for their views.

How do we split stories in Agile or What is story-splitting in Agile?

Splitting a story into smaller units is called decomposition.

Few important ways in which we can do decomposition i.e. split stories are:

  • Functional decomposition – splitting based on functions
  • Processes decomposition – splitting based on process steps
  • Structural decomposition – splitting based on component pieces

Examples:

Functional decomposition:

  • Story: Blogging feature
  • Functions: Creating blog posts, Editing blog posts, Publishing blog posts, Tag blog posts, etc

Processes decomposition:

  • Story: Employee onboarding
  • Process steps: Hire employee, Complete formal documentation, Assign work location, etc

Structural decomposition:

  • Story: Dashboard feature
  • Components: Widget A, Widget B, Widget C, Widget D, etc.

The individual split-user-stories created as a result of decomposition are added to the Product Backlog.

 

Backlogs:

In Agile, backlogs help us to keep a track of work left to complete on our product.

There are two types of backlogs in Agile

  • Product Backlog: All the work left to complete on a product
  • Sprint Backlog: The work left to complete in a given sprint committed by the team.

 

Product Backlog:

  • In the beginning of the project, there is little clarity on the work to be done.
  • There is no list of fleshed-out user stories to begin work on.
  • During the first sprint-planning meeting, the Product Owner has a product backlog with a list of initial items (stories) called the Product Backlog Items (PBIs). The goal of the meeting is to estimate work involved in the stories and get them assigned to the first sprint.
  • The PBIs don’t look like user stories. They usually describe a story in a shorter format so that they are easy to view as they are a list of dozens or hundreds of items. However, each PBI has a user story and an acceptance criteria inside it.
  • Example of PBI Names: Account creation functionality, Shopping feature, etc
  • The PBIs has two important features:
    • They are prioritized and ranked i.e. the list is sorted with the most important items on the top and that is also the order in which they should be completed.
    • They are sized or estimated in story points.
  • In short, a PBI is an item on the product backlog that has a user story, acceptance criteria, and other data. It represents a unit of business value on the product backlog. 

 

Before we move to Sprint Backlog let us understand the concepts of Story Points and Velocity. These concepts will help us to decide on how to move the stories from product backlog to sprint backlog.

Story points:

  • They are a way for the team to determine the complexity of a story. Based on the complexity the team can estimate the relative development effort. Hence, story points are an estimate of relative development effort.
  • The effort considers both the development and testing effort.
  • They are numbers that give relative sizing of user stories.
  • Sizing options:
    • Small/Medium/Large/Extra-large
    • 1, 2, 3, 5, 8, 13,…

Velocity:

  • The number of story points a team can deliver in a sprint.
  • After a couple of sprints, the team gets a good idea of the amount of story points it can deliver in a sprint. They then stick to a fixed velocity as the project moves forward.

 

Sprint Backlog:

  • We decide what we as a team would commit to complete in a sprint.
  • Assume that we estimate our team’s velocity at 20 story points.
  • We now select the first several PBIs that add up to 20 or fewer story points.
  • We can now begin work on the items.
  • The sprint backlog is everything the team is doing for a given sprint, and is managed by the team.

 

Story Mapping:

  • Prioritized product backlog may not be the best option to deliver value-oriented products in each sprint.
  • We cannot just select the top items in the product backlog and develop them. In the real world, things are rarely linear.
  • To deliver the most valuable product in each sprint, we have to work on multiple stories that may not be linear order in the product backlog.
  • To solve the aforementioned problem, enter story-maps!
  • Story-maps are a graphical representation of a product backlog and sprint backlogs.
  • You first organize the stories in your product backlog based on the functionality and priority. Then the story-map will give you a clear decision-making model to help you decide which user story to place in which sprint.
  • For more info please refer to the following articles:
  • https://agilevelocity.com/story-mapping-101/
  • https://blog.easyagile.com/anatomy-of-an-agile-user-story-map-4ecb6a508d94