Using “User Stories” To Capture What the Customer Really Wants (Conclusion)

Back to Knowledge Bank
Posted by: briansittley Comments: 0 0 Post Date: February 26, 2015

who what whyIn our last post here we looked at a simple model called the User Story that can be employed to help ensure that what a customer needs their software to do becomes, in the end, what it actually does.  If you’ve read the simple basics in our prior post — with emphasis on the User Story’s Who, What and Why — then our example today should help seal the deal.
Our example comes from an actual client with a need to which most companies can relate.  Our customer produces products requiring multiple steps and assembly processes for the RV and marine industries.
Who:  The ‘Who’ is our client’s General Manager.   The GM is responsible for ensuring that production on the floor runs smoothly and efficiently, ensuring that work crews across the various production zones are being utilized as effectively as possible.
What:  The GM wanted a custom report that would give him sales dollar volume currently sitting in customer orders, arranged according to each order’s work center on the floor.
Why:  Like other companies, our GM uses order backlog as a proxy for more detailed production and work center/routing cues.  That makes sense because it’s a great ‘seat of the pants’ barometer for how busy the folks on the floor are likely to be in each area of production.  They want to look 3 days out and know how “balanced” the flow will be on the production floor.  (Or in production floor parlance: Which butts to kick, right?)
So in simple terms: The GM (Who) needs a specifically filtered report based on orders (What) in order to balance the workload on the shop floor (Why).
The value lies in being able to keep promise dates, keep the floor busy, optimize production, and maximize throughput while minimizing labor costs.
Some experts, like the development team at Rally Software Development would say that this User Story gets us started, but the team needs more: they need the 3 elements of a user story – the Card, Conversation and Confirmation.  That’s pretty easy too…
The Card is the overview of Who, What & Why — using an index card as a metaphor (and sometimes literally) as the space for telling the succinct story.
The Conversation results when the Card is used as the basis for a discussion between the client and the provider, as they develop a shared understanding of the desired functionality, goals and constraints.  Here the consultant should be asking questions to ensure a clear and mutual understanding.
Finally, The Confirmation should be captured after the Conversation, in the form of “acceptance criteria.”  In other words, how will the results be tested to ensure the need (What, Why) is met?  How will the customer confirm that the story was properly implemented?  The acceptance criteria are the conditions of satisfaction that confirm that the user story has succeeded.
That’s it then: Who, What Why… and the 3 elements of Card, Conversation and Confirmation.  The User Story can go a long way towards ensuring a successful implementation is occurring at each step along the way.
 

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Knowledge Bank