I'm fascinated by the attraction of the Agile User Story with requirements writers and the effort to make it be a final usable Requirement. Stakeholders format their needs from their view using the simplistic Agile user story. That list of stories then becomes the requirements document or backlog with little analysis. It can reel in any amount of confusing scope easily much like a black hole will attract anything it gets close to.
Related Articles
I wrote about rewriting user stories into business' goal targeted requirements in my last blog and my best words to describe it is as a value-driven approach. After writing that I found that Elizabeth Keogh (@lunivore) suggested that business value is more important than the user role back in 2008. But I want to go deeper. I find that the detail level of the user story is unusable as a coder except to start making informed guesses.
Project value
Needs elicitation is the common starting point of a project. This is normal. Needs are selfish. But needs can't be met until everyone decides what the Business goal is that the needs address. The goal should be to solve a business problem. The agreement on the problem statement becomes the starting point for gathering focused needs.Once there is a problem statement, the needs can be framed in that context instead of the individual project stakeholder or customer. I don't think the stakeholder is going to give you any amount of money to write your code so why tailor the project to each one of them? It's the business that gains the value; it's the business that pays the bills; it's the business that should be the context of the requirements.
User story versions
Scott Ambler, a prolific Agile writer and process thinker, outlines the user story on his Agile Modeling site:- pre-2008: user story begins as an informal simple "I want a ..." kind of statement
- 2008+: Mike Cohn adds the party benefiting from the value In User Stories Applied with the format of "As a (role) I want (something) so that (benefit)."
- Students can purchase monthly parking passes online.
- Parking passes can be paid via credit cards.
- Parking passes can be paid via PayPal.
As a Student I want to purchase a parking pass so that I can drive to school.
The Elizabeth Keogh user story of the same story would probably look like
In order to drive to school, as a Student, I want to purchase a parking pass.
Both of those examples have the Student getting the value. If I'm the starving student, I want to park free. Did you people ask me? None of those are real benefits. After I get done changing this need into a value-driven requirement it will look completely different:
The school sells permits to park vehicles on school property.
You'll see the benefit as a large scope requirement that traces down (is a parent item) to this requirement. The user story is a needs elicitation tool but with a process flaw. The user stories are passed on the the programmer who think they have structure. The reductionist user story rearranges the words of the "requirements" you find in an Excel spreadsheets and passes them on to development.
Needs vs requirements
A need is a statement of any scope granularity, any priority, with or without a responsible party, and either functional or not. It could even be a design as envisioned by the stakeholder trying to grasp how to convey what they think will get the job done. Needs have so many shapes and forms that they can't be processed easily. They have no structure which is why "requirements" meetings last so long. They are really needs elicitation brainstorming sessions.
Needs have to be rewritten into organized requirements. A good requirement has structure. That structure is testable. A good set of requirements is complete. That completeness is validated by a model and the stakeholders. Structure and models take training and time to do well. Stakeholders don't have that time. Analysts do.
The biggest problem for my students in my Business Analysis class seems to be stopping at a good enough stage where the needs are all lined up neatly with enough words so it looks passable. The critical thinking skills should kick in to test the requirements but the tests are not well understood about what the goal is for a good requirement. Programmers don't communicate and use their tool-driven BDD/TDD/XDD style processes to wrangle the statements into some code.
The biggest problem for my students in my Business Analysis class seems to be stopping at a good enough stage where the needs are all lined up neatly with enough words so it looks passable. The critical thinking skills should kick in to test the requirements but the tests are not well understood about what the goal is for a good requirement. Programmers don't communicate and use their tool-driven BDD/TDD/XDD style processes to wrangle the statements into some code.
Value-driven requirements
My value-driven approach for the first parking pass requirement would be much more detailed and focused on the school that is paying for the project. A goal accomplishes business value in a functional requirement statement and can be rolled up to a goal group. A goal group expresses larger scoped business values. For the goal, rules express how the functional requirement is to be executed.- Goal group: The school offsets direct costs for parking.
- Goal: The school sells permission to park vehicles on school property.
- RULE: parking permissions are valid in one month increments
- RULE: permissions are only offered online
- RULE: permissions can be paid for with credit cards (Visa, MasterCard, AmEx) or PayPal.
- Goal group: The school provides a secure environment.
- Goal: The school controls vehicular access to school property.
- RULE: Drivers access school parking lots through entrances requiring permission.
- Design recommendation: parking passes should be used as permission evidence.
The Student of the user story is a valuable piece of requirements information but not for the requirements statements. It should become a persona as long as descriptive details are added to make them more real. Personas should be used as a design step in the project and for testing but not for requirements. You'll also need an Instructor or Employee persona.
A parking pass is a permission mechanism that can be replaced with another solution and not affect the requirements. That makes it a design choice and unless there is a constraint on the project for doing it, it is not worded in the requirements statements. It should be captured as a stakeholder idea for a solution in a category of design recommendations.
My goal follows a similar structure as Alistair Cockburn's goal driven use case except for adding the rules directly into that scenario if the rules are not reusable in other use cases. Many goals should be able to be found that roll up to a goal group. And goal groups can be drilled down into to find other goals. Business value becomes more strategic as you roll up your goals.
It's the focus on solving our own needs as we see them instead of creating value out of solving a business problem that has us creating confusion in requirements. Encourage the stakeholders to start thinking as a team from the business viewpoint and find the value that is in your project.
A parking pass is a permission mechanism that can be replaced with another solution and not affect the requirements. That makes it a design choice and unless there is a constraint on the project for doing it, it is not worded in the requirements statements. It should be captured as a stakeholder idea for a solution in a category of design recommendations.
My goal follows a similar structure as Alistair Cockburn's goal driven use case except for adding the rules directly into that scenario if the rules are not reusable in other use cases. Many goals should be able to be found that roll up to a goal group. And goal groups can be drilled down into to find other goals. Business value becomes more strategic as you roll up your goals.
It's the focus on solving our own needs as we see them instead of creating value out of solving a business problem that has us creating confusion in requirements. Encourage the stakeholders to start thinking as a team from the business viewpoint and find the value that is in your project.
