source: Flickr |
Project phases
There's a basic flow to managing a project:- Figure out the problem (strategy)
- Break the problem down into chunks (analysis)
- Plan what we have to do (design)
- Do/build each of the chunks (development)
- Make sure we did it right (testing)
- Use the solution (production)
But I think we should add a step that will influence how we write our documentation. It's the step where someone pays for the project. That someone is the project sponsor and they want to see some sort of value returned for the investment of time and money on the project.
The User's Story
The common form of a user Story in the Agile world goes something like this:
As aThe type of user> is important so that we can wrap our security access controls around them in the design stage. And the type is also useful when we are eliciting other types of user stories during a brainstorming session of some sort so that we can come up with related user stories from the same sort of user. A use case would combine similar types of users into one actor so that the interface is simplified when moving into design., I want so that
The some goal> is important because it provides a similar sized chunk of scope that allows a project manager to create a work breakdown structure with work packages. I also find it useful to provide an architectural sized component based on the goal in software.
But there is trouble here. We can ask for the goal from the perspective of the user or from the business. It's been my inflexible rule that you never ask a stakeholder the priority of a requirement. The expected answer from any manager worth their salt is that they gotta have it. Ask a room full of managers what the priority is and you'll make your meeting much longer than you wanted to.
One of the lessons I learned from Incident Management in ITIL is that you measure priority of incidents as a combination of impact and urgency giving you some hard numbers to work with. Impact is the number of people affected or marketplace and urgency focuses on the perceived value often backed up by a level of management to manage that process or measured by how much you want that new 4k monitor.
But this priority should be from the view of the business and not from the user of the product or service. If we asked the user what they wanted (akin to asking a 7-year old what college they want to attend) they will tell us all sorts of useless goals. Maybe it really is an important goal of that stakeholder to own a kitten or draw seven red perpendicular lines but the business is not going to find value in it.
The some reason> then expands on the trouble that started with the user's goal. They'll tell you a wonderful reason why it's important to them. But we're looking for business justification here and in my mind, I'd want that justification to be in the form of a higher level business goal. When things go right, the business goal is in mind, but it's not a constraint of the format.
I know that in Extreme Programming, where the user story came from, user stories were seen as an estimation tool. They also were written from the perspective of the system. That makes sense to me. I need a metric to measure my project where all the units are of the same size. That way I can make that PERT chart make sense in terms of scope.
The System's Story
And why is a basic functional requirements statement written from the perspective of the system? Because the requirements have to be executed by the system and tests confirm that. So we write it that way. But why not write from the perspective of the user? Let's try a test. A user story to run a report for monthly sales goes like this:As a sales manager, I want to see a sales report, so I can identify the sales reps who are under-performing.What's the value there? Aren't the under-performing sales reps making money for the business? Is this a personal agenda or a goal that isn't well thought out? How about we try the story from a business perspective?
As a sales manager, the system shall create a sales report, so that sales trends can predicted.Or another version from a different user might be:
As a marketing manager, the system shall create a sales report, so that marketing can budget for advertising.I can see the business value in sales forecasting and marketing budgeting. What I see in the other story is a sales manager who creates churn in their sales division which is not value to the business. The requirement is the same.
User story to requirements
So I'm not going to try and change the user story because it's a good elicitation tool. It does not have enough detail to be a good way to deliver requirements to anyone downstream in design or programming. But I did want to raise the issue of the two-faced nature of the statement. In the statement, we can direct the value to the stakeholder or better, we should direct the value to the Business.
My recommendation is when using user stories, that we take those stories as a user's statement of what they want and then rewrite them as a good requirements statement. In a use case format we would have
Stakeholders (interests): sales manager (wants forecasting), marketing manager (wants budgeting)As it was, I figured out that all the business value reinforcement I had been getting from other sources over the years caused me to rewrite the user story in a different format when adding it to my lecture. So in the end, I made a mistake about the real format of the user story and learned from my mistakes. No, I didn't get a kitten.
Actor: report reader
Use case: create sales report
Related blogs
- Re-inventing usable requirements: Value-driven projects & the failure of the Agile user story
- Don't be a LeBron and write user stories for you. Create team value with these examples.
