I think that organisations come to Agile because they are desperate for improvement. They think the problem is to do with poor software delivery, but I believe the problem is poor requirements (or if you prefer poor ‘user stories’). Which suggests that Scrum/XP solves the wrong problem. There is no real issue with talented developers delivering code. The problem is the business being unable to state what they want clearly. Scrum/XP skirts around the issue of user story management. I think where we go from here is we split into an Agile Requirements practice (ARP) and an Agile Delivery practice (ADP). ADP works well. ARP doesn’t. Jacobson’s view of the essential issues of concern in software engineering echos this approach. i.e. requirements don’t belong in delivery, rather requirements are a formal input to delivery. http://www.ivarjacobson.com/process_improvement_technology/essential_unified_process_software/

I’m a BA working on ideas for making stories better by the time they get to the Sprint planning meeting so planning poker can be done with enough information to have confidence. I do this using a requirements pattern language I’ve been using it since 2003 and it works well. The pattern language works for transactionally-oriented database applications and includes patterns for driving out common personas, minimal persistant representation, data maintenance, lifecycle class, and management information.
The application of the pattern language ensures the upfront requirements work does not take longer than it should. A first cut of the requirements hierarchy tree is always available within a week. The whole set of ‘conversations’ around each candidate user story is almost always done within five weeks – then the sprint planning meeting can start, and it is guaranteed to be short and sweet.
The implementable story hierarchy has project stories at the top. These are akin to ‘Jacobian’ use cases in that they represent the achievement of the user/actor/persona goal. They are the top level of the requirements ‘tree’ and act as the basis of the requirements table of contents. The project stories decompose into release and iteration stories. The entire hierarchy can be traced back to all the business inputs from interviews and workshops. The approach introduces a new definition of ‘epic’ to no longer mean ‘a big story’ (not that helpful) to a more interesting definition that includes:
• Enterprise stories
• Back stories
• Project stories and tests
• Release stories and tests
• Iteration stories and tests
• Constraints
• Implementation tales
• Non-functional requirements
The definition of ‘epic’ shows how all these elements fit together and is supported by graphics and spreadsheets. This approach is really useful early in the project lifecycle. It can be applied during feasibility, and in ‘ideas management’ where management has to decide which projects to fund in the first place.

I’m interested in:
• how to bring the PMO onboard
• how to reconcile the need for ‘governance’ with Agile
• how to give senior management confidence
• what to do when the customer isn’t full time available
• reconciling enterprise stories, project stories, release stories, iteration stories, constraints, acceptance criteria etc. into a big picture
• how upfront requirements/stories can still be Agile (keep it simple, but no simpler than it needs to be)
• a synthesis of Agile modeling and the best lightweight aspects of UML

I’m blogging at masterstoryteller.co.uk. I also write at princelite.co.uk. Visit me!

Peter

I don’t use stories for work management either. Stories flow through the production system only as a side effect of their work items flowing through the system.

Stories aren’t descriptions of work, so they aren’t eligible as work management artifacts.

They inform the people doing the work, giving them (hopefully) an understanding of how they benefit the lives of their users with the software that they’re making.

Thanks for going into practical details that are hard to come by. And great to see additional wisdom the feedback too.

If you can express user stories with as little mention as as possible of any software, then you’re getting closer to the purpose of user stories, which isn’t to specify software but to communicate a contextualized description of a problem.

So, instead of: As a nurse I need to be able to set my default location so that I am viewing my preferred data when I log in to the Nursing Station app.

Try: As a nurse I view my preferred data in order to pay attention to {ah ha! something is missing in the analysis! the root cause/motivation!}

There are a handful of weaknesses in Scrum orthodoxy surrounding user stories and contextualized, user-centric design.

Instead of thinking wishy-washy geek distractions like “feature” and “business value”, consider the user’s goal in the work, and the motivation for the goal. This leads to a better analysis of context, which inevitably leads to systems that are a better fit to the task for having more user context communicated through user stories.

My user story format is:

As a [role] I want to [goal] so that [motivation]

I try to drop the “want to” filler and see if I can get right down to an imperative expression of what “I do”, rather than the passivity of something I “want to do” or “need to do”.

The goal is this: As a user, I tell you what I do so that you build software to support what I do.

The goal of user stories isn’t to describe software or features, it’s to communicate the context of people, their goals (the work they are called to do) and their motivations for doing it (context).

Also, the INVEST model is shaky at best. It’s an elaboration on user stories that Scrum added that is only useful in specific contexts.

User stories do indeed have dependencies when they’re used to sequence and schedule work. Which is why I personally don’t use user stories as work items, but as bearers of context to work items.

So, how do you communicate the specifics of logging in and the default location that are essential to your user story above? Flip the card over and write those details as acceptance criteria. Or, if you’re familiar with Context Specification, you can use it.