This article discusses the clarity of requirements for Agile software development and explains how you can use a four-step process for gathering them with the four levels of agile requirements.
Author: Sally Elatta, Agile Transformation
Don’t you just love the word ‘Requirements’? It’s just so clear isn’t it – NOT! Have you ever heard your business customer say ‘I’ve already given you my requirements’ and the team then says ‘We haven’t received clear or detailed requirements’? The other side to this is when the team tells the customer ‘You are giving us too much details, don’t tell us where the button goes on the screen, just tell us what you want’. No wonder we have so many requirements related issues on our projects!
During one of my previous PMI webinars we talked about Agile Requirements – Breaking Down EPICs and Prioritizing. I will take a stab through this blog at summarizing the levels of Agile (and frankly non Agile) requirements and how you can use a four-step process for gathering them.
First, let’s start with the picture below. The picture shows four levels of requirements, and also on the left is the four-step process for gathering requirements.
Agile Requirements Levels
Visioning: This is the initial step of gathering requirements. The goal is to help identify all the Themes and some features desired. This exercise begins to define the scope of what is expected.
Brainstorming: The goal of this step is to identify all the features and stories desired. The key here is Breadth First, Depth Later. So instead of discussing the details of each feature and story, our main goal is to FIND all the features and stories.
Breakdown: The goal of this step to break down and slice the stories that are still too large (EPICs) into smaller chunks. You probably have already done a lot of slicing during brainstorming, but as you comb your backlog, the team will realize that some stories are still too large to be completed within an iteration (usually 1-4 weeks). Slicing stories is an art and I will dedicate an entire blog to it!
Deep Dive: This is the step everyone wants to jump into right away! Yes, finally, let’s talk about the details. What will be on the screen, what are the exact business rules and how will we test them, what will the detailed process look like, what are the tasks we need to get done to complete this story. Jumping into this level of detail upfront during the initial phases is one of the main reasons contributing to scope creep later during the project.
Suppose we are developing a system for an online job posting website named OnStopJobs.com. Here is an example of what the requirements could look like based on the levels above:
1. Employer Area – Theme
a. Manage Jobs – Feature
1.As an employer, I want to post a job so others can find it. Story
2.As an employer, I want to modify a job posting so it is correct. Story
3.As an employer, I want view a list of my open job postings so I can analyze them. Story
4.As an employer, I want to expire a job posting so no one can apply. Story
b. Manage Applicants
1.As an employer, I want to view the list of recent applicants so I can respond to them.
2.As an employer, I want to view the list of applicants for a specific job positing so I can qualify them.
3.As an employer, I want to select the top candidates so I can interview them.
You should gather the levels above (Themes, Features, Stories) upfront when you are planning out your release, especially if you have the traditional projects with begin and end dates. We usually spend more effort on the stories that are coming up in the next few iterations or the next release.
The Deep Dive is where the main difference lies between Agile and Waterfall. Traditional teams would gather this very detailed information upfront for ALL the stories on the backlog, where Agile teams will gather these details Just In Time for the next stories, which is one or two iterations before that story needs to be DONE.
Here is an example of what the details could look like for this selected story: “As an employer, I want to post a job, so others can find it.”.
Acceptance Criteria/Tests
How will we know when we’re done:
1. UAT1 – Verify that only an authorized user with a valid employer account can post a job.
2. UAT2 – Verify that a duplicate job posting cannot be entered.
3. UAT3 – Verify that the posting date is past today’s date.
4. UAT4 –Verify that the positing expiration date within 90 days.
5. UAT5 – Verify that the screen fields pass our standard field format rules.
6. UAT6 – Verify that all required fields are entered.
Acceptance criteria are the ‘details’ of the story and they are considered primary requirements in Agile. We gather them upfront before any development begins.
Sample Tasks
The work we need to do to get this done:
1. Create a database table to store the job posting details.
2. Design and build the screen for job posting.
3. Develop the logic for UAT1 to pass.
4. Document/record the on page video help for the job posting page.
5. Perform user acceptance testing.
6. Deploy the code to the test environment.
7. ….. others..
UI Prototype/Wireframe and Activity Diagrams
These could be hand drawn sketches of the screen or the process steps involved for the system to accomplish the process defined.
Quiz Time – What is What?
Would you like to test your skills and ability to differentiate between the various levels of requirements? Take a look at the list of requirements’ below and jot down your thoughts on if each item is a Theme, Feature, Story or the Details of a story. I have purposely made them tricky and some of them could have two answers depending on the context you define.
a) We need the ability to filter our reports by date and group #.
b) We want to manage user access to the site and limit who has access to what.
c) We want to make sure that only Managers can access the salary data.
d) We want customers to pay using credit cards online.
e) We want to verify that Discover card payments are not allowed.
f) We want scheduled and ad hoc reporting.
This content was originally published in August 2011 on the blog of http://agiletraining.com/ and is republished here with permission of AgileTraining.com