Many of the practices that we apply in agile development teams emphasis deferring commitment. This is one of the ways we stay agile. If we have written a sentence on a story card and subsequently decide we don’t need that story we can rip it up, very little has been lost. Compare this with costly requirements specifications, a small change can trigger significant re-work.
In the same way, when specifying a user interface it can be helpful to defer commitment while expressing the need succinctly. Often we can use white boards and/or paper mock-ups to develop screen flows in meetings with customers. This can help us play with alternatives and walk through scenarios while avoiding the cost of mocking up in html or photoshop.
Balsamiq Mockups offers the logical next step. By retaining the style of a paper mock-up we can avoid becoming too attached to one design. A slick user interface helps us build screens quickly and provides most of the components we are likely to need.
However, for me the killer feature is the confluence integration. I use confluence every day, many of my clients use confluence for project documentation, this integration means that the documents can be found by all concerned, edited in place and version controlled.
Technorati Tags: Agile Requirements, Balsamiq Mockups
I should start this post with an admission – I do not claim credit for any original thought here. What follows is taken from my own notes and has been accumulated over a number of years. I most recently tweaked my own notes and the way I explain this stuff after hearing Jeff Patton’s talk from the UK Lean Kanban conference on infoQ.
The way I think of splitting user stories is through identifying axis. Some examples of axis are:
- Steps in a workflow
- Usability
- Quantity of data
- Asymmetric value
- Stakeholder needs
Steps in a workflow
The first of these is fairly self evident. On a recent project we had the need to implement a user story to purchase an item. This fell into an initial workflow design and mock-up stage followed by 4 user stories relating to the four stages of the workflow, checkout, select shipping method, submit order, order confirmation. This approach enabled us to deliver working features based on mock-ups followed by iterative improvement.
Usability
Another approach to the same problem could have been to split along a usability axis. This would involve and early “ugly” version followed by iterative usability improvements. This approach can be more effective if the screen design is novel and uncertain or the technical risk around order submission is being brought forward as a mitigation. A further usability axis would be to separate core functionality from enhancements such as auto-completion and other AJAX magic. A further example that comes to mind is a search capability, initially searching was by full words only on one field, gradually the back end was enhanced to do partial words and check multiple fields. At the same time the search results view was being enhanced to enrich the user experience.
It is in this category that we see Patton’s considerations of Bare Necessity, Capability & Flexibility, usability, performance, sex appeal manifest. His final axis is Safety which more clearly maps to stakeholder needs below.
Quantity of data
Quantity of data can be an issue where it significantly impacts the size of a task. For example where the datasource differs. It may be possible to establish a workflow while limiting the variety of variation of inputs or scenarios. An example might we limiting a registration form to accepting only a minimal customer details or limiting a report to showing a subset of the data. The later approach may allow some proof of function and review of layout earlier than if all data sources / types / fields were considered.
Asymmetric value
Value is a core consideration with user stories. It may be worthwhile considering how the value of the user story is gained. I worked on a system some time ago which was incrementally adding features in order to retire an older system. Our key goal was to minimise the users interaction with the old system. The user story under consideration was “create and trade financial instruments”. It turned out that while at first glance these were an atomic unit the users would trade instruments many more times that they would create them. Thus, we could reduce the users interactions significantly by providing the trade facility requiring the users to, in the short term, create instruments through the older system.
Stakeholder needs
Despite the name “User Stories” and stakeholders needs can be represented as a used story. During development it can be useful to view a user story from the perspective of security, operations, finance (and others) where one of these places a significant burden on a user story it may be appropriate to separate the two goals. An example of this can be as simple as data validation e.g. post codes or Captcha fields which do not benefit the user but some other stakeholder.
If all else fails
We could always fall back on using architectural lines to split a user story of breaking out a component that needs to be built. This approach is often at the top of the list when developers begin to consider splitting stories. I prefer to leave this as a last resort, we shouldn’t deny that it is an option but as my experience in splitting these things has increased it is a resort that I find myself reaching for less and less.
Technorati Tags: Agile Requirements, User Stories
Much has been written about User Stories however, it is still a subject that I find people struggling with.
In this post I intend to review what are the choices that we make that enable us to claim a requirements approach as agile and how can user stories (when applied well) help us achieve this agility.
An agile approach to requirements should
- Defer investments
- Support just in time elaboration
- Encourage collaboration
- Support planning
The most common approach to agile requirements is User Stories. A user story represents a need on behalf of a specific stake-holder.
What is a user story?
User stories represent a need in terms of the individual who would benefit and the goal they are trying to achieve. For example an on-line book seller might have the story: As a customer I would like to search for a book by ISBN so that I can make a purchasing decision.
User stories can also be written on behalf of stake-holders who may never interact directly with the system, for example: As a support representative I would like the system to log activities and errors so that I can establish cause of a failure. In this way stories can be written to represent other aspects such as audit, testability, extensibility and performance requirements.
By representing stories in this way we can provoke valuable discussions regarding true need of a feature and it’s relative priority in the backlog. It is not uncommon to find teams working on what seems like a sound requirement that, when represented in this way, is shown to have little or no value.
So how do user stories meet the desires stated above?
Defer investments
A user story can be expressed at a very high level early in a development project. As the story moves over time towards the top of the backlog it can be split. This approach results in small items at the top of the backlog and large items at the bottom. The items at the top have been split and appropriate details added such that they are both small enough to deliver in an iteration and detailed enough that work can begin. Low priority items may never justify this degree of investment.
Support just in time elaboration
A story is often said to be a trigger or promise to have a conversation. With an on site customer a card with a few notes may be sufficient to trigger that. With non-instantly available customers we may choose to gradually build up the detail and supporting information (e.g. acceptance tests / criteria) prior to development commencing. The key here is to avoid the temptation to elaborate all of the user stories up front.
Encourage Collaboration
As user stories are elaborated we will need to engage with business stakeholders, user interface/experience designers, testers and developers (maybe others too) in order to establish the true requirement. As conversations of this type continue throughout the project we achieve a shared appreciation across what could other wise become distinct areas of the project.
Also, the way we handle these things can further enhance collaboration for example WIP limits and short iterations both place a tension on teams to find ways to collaborate.
Support Planning
Planning is usually necessary to answer questions like; when will it be done? and how will I know it’s on schedule?
User stories are often estimated using planning poker. This provides a low cost way to compare relative sizes. We can do this at low fidelity with very little information to support long term plans. For shorter term targets we can break stories down and add detail to gain a higher fidelity estimate. When planning an iteration we may be able to break down stories to such a degree that they can be scheduled and delivered in a couple of days. Where this is not possible a task break-down may be used to gain an appropriate fidelity for setting expectations for the next 1-4 weeks.
So where can I find out more?
See what Ron Jeffries has to say on the subject of the 3 critical aspects of user stories
- Card
- Conversation
- Confirmation
Also, Mike Cohn has plenty to say on the subject. Not to mention his book User Stories Applied which is available on google books!
What next?
In this short post I’ve mentioned splitting user stories more than a few times. In the next one I’ll provide a number of techniques that will support you in ensuring that your User Stories are the right size for today.
Technorati Tags: User Stories, Agile Requirements
