User stories are a description of what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome.
User stories are different than requirements. When using requirements, it is likely that the developer implementing the requirement will be presented with an implementation task or a design document and be constrained to implementing as specified or as designed. A user story removes invisible constraints by focusing on the outcome desired by the user. The developer doing the work will see the user story, will be able to better understand what the user needs, and will be able to participate in or even own the specification and design of that story. User stories provide engineers more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.
So, if you were starting a software company with your own hard-earned cash, would you use user stories or not?
Next: Poll - Product Backlog, The Benefits
2 comments:
I don't really like pushing the design issues down to the whole development team. I'd prefer one visionary, supported by different specialties.
In that case, the visionary needs to know and understand how the users work, but that needn't be formalized or distributed.
Of course that's all your eggs in one basket, since if the visionary fails the product fails, but that's always been a better approach than design-by-committee (I think).
Hi Paul,
No problem. The benefits of user stories can be experienced in a number of ways. For instance, you might have the visionary be the product owner and have them create the stories and arrange them in the backlog.
If there is a lot of design involved that requires lots of coordination, you might have the stories go through a first pass with the domain expert for suggested implementation approaches.
How you achieve coherence and integrity of vision is going to depend on your circumstances. But, the main value of the user story even in the case you describe is that when the people doing the implementation start working on the story, they see the direct connection to what the user wants. Thus, even if the design is already attached to the story, if they spot a problem during implementation of the design that is counter to the user story, they can raise an exception (so to speak).
As you allude to, the more that you can leverage the visionary, the better of you will be.
Post a Comment