The Four Levels of Agile Requirements
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’ll 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 4 levels of requirements and also on the left is the 4 step process for gathering requirements.
: 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.
: 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.
: The goal of this step to breakdown 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!
: 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 site 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 raditional 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:
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 tables 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:
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’ve purposely made them tricky and some of them could have two answers depending on the context you define. I will share the answers in my next blog so stay tuned!
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.
Please post a comment or question below and share with us your own experience and challenges with requirements. Do the levels above make sense? Do you see value in organizing requirements this way? Please share any tips you have with managing the levels of requirements.
You Don't have Requirements!
Categories: Project Requirements
PMI Releases Business Analysis for Practitioners: A Practice Guide - free download for the next 6 months!
Did you know that according to research PMI conducted in 2014 that only 64% of completed projects met their original goals and business intent? That 16% of projects in the last 12 months were failures? That 37% of organizations reported "inaccurate requirements gathering" as the primary cause of project failure? That poor requirements management practices are the second leading cause of project failure, second only to changing organization priorities?
Thankfully, good business analysis on projects and programs result in customer expectations being met, engaged and committed stakeholders, projects that are more likely to be delivered on time and within scope and budget, implemented solutions that provide business value and meet stakeholder needs, all while developing reusable business analysis competencies for future projects.
The above are quotes and paraphrases from the recently released the Project Management Institute's 227 page Business Analysis for Practitioners: A Practice Guide. It is available for free download for the next six months. Written by experts in the field, it is chock full of solid tools and techniques to help you succeed on your projects and programs in the area of business analysis and requirements management.
Why not get it today and learn more about Needs Assessment, Business Analysis Planning, Requirements Elicitation and Analysis, Traceability and Monitoring and Solution Evaluation? From SWOTs and Five Whys to Use Cases and Wireframes, and everything in between, you will be glad you did!
And keep an eye on this Blog for possible posts by some of the Practice Guide's core and review committee members, among them Elizabeth Larson, Rich Larson and Ellen Gottesdiener.
Get your free copy here for the next six months at this link:
My colleague Beth Ouellette and I had a little fun at the Phoenix PMI Congress with our presentation of Top Tips for Effective Requirements Management collected through a survey of the 18,000 member Requirements Management Community of Practice and through the webinars presented to the Community over time. We thought we would liven things up a little by presenting short vignettes acted out by volunteers from the audience. Following are the names of the skits with a brief explanation of what they were meant to convey. The first five convey project issues. The rest show actions you can take to manage requirements to help drive project success.
We wrapped up the session with the seven keys to requirements management success:
What has been your experience with the impact of requirements on your projects? Have you experienced any of the project and requirements issues we tried to get across with our humourous skits? Maybe you were at the session in Phoenix and have something you'd like to add.
My Uncle Bill used to tell us that no matter what type of hotel or where it was located, no matter how many of the hotel staff he talked to in advance of their arrival, Aunt Roslyn would look at the assigned hotel room, find it inadequate, and request a change of rooms. When we were younger, we always felt sorry for Uncle Bill. How patient, how long-suffering he was to put up with the inevitable bother of changing hotel rooms.
However, as we’ve aged, my husband and I find ourselves changing hotel rooms more frequently. In Part 1 of this blog, I wrote about the feature fallacy, citing the example of a hotel front-desk clerk who gave us a hotel room with features we didn’t want, but without those we wanted. After trying unsuccessfully to convince us to stay in the assigned suite, he told us respectfully but firmly that no other rooms were available and change was not possible. In desperation we agreed to pay a fortune to upgrade to get what we originally asked for. Nevertheless, the clerk appeared unhappy. Clearly, the change request was an anomaly and upset his process.
I suspect that many of our sponsors and other business stakeholders are reluctant to request changes because of our body language, because of a burdensome change process, or because they are used to being told “you can’t have that change. It’s out-of-scope.”
In looking back, it seems that we’ve been less likely to change rooms when we’ve taken a virtual tour of the hotel prior to booking a room. Unlike photos taken at just the right angle to make a tiny, bare room look cozy and comfortable, a virtual tour provides a broader perspective of the room in relationship to the rest of the hotel. Pictures provide a structure for us to help the stakeholders discover their requirements, and one of the best ways to provide pictures is prototyping. Unlike static screen shots or wire frames, prototypes that allow our business stakeholders to “use” the end product help elicit not only their requirements, but also those hidden expectations. Even when the prototypes are low tech rough drafts drawn in PowerPoint or on easel pads, they are an effective elicitation technique.
I’m not sure much will change on future vacations. But that’s OK. Few hotel clerks are as crabby as the one above. We have generally found them to be friendly and flexible, like most of the business stakeholders we work with as well. We practitioners just need view change positively, knowing that it will happen, and with tools available to uncover as many expectations as we can.