In Scrum, work is expressed in a three-tier hierarchy like Epics>Features>Stories for artefacts that describe functional behaviour. Epics and features are used to describe the larger intended behaviour, but all detailed implementation is described via stories. A user story captures details of business value that a team can deliver in an iteration. A user story is more to do with the perspective of the end user, and teams are encouraged to think from the perspective of who will use it. User story differs from the traditional requirements aka use case model which are as detailed as possible, a user story is defined incrementally and is refined in stages which covers the brief description of the need, backlog conversations among stakeholders to solidify the details and test criteria that confirms the story completion.
User stories should have enough basic information like who wants what functionality and why is the functionality needed, which can be related to Mike Cohn template
As a [end user role], I want [the desire] so that [the rationale]
or
As a <user type>, I want to <function> so that <benefit>
So, Users, feature and benefit (business value) are the most important pieces and obviously business value is the most important piece as it baselines the real reason behind that story and its importance to be part of an iteration. Knowing how users will benefit will allow developers to build better software. If that part is not highlighted properly then we may end up building a software that merely satisfies the customer requirements but don’t delight them.
- The INVEST mnemonic checklist helps to determine if a given user story has been properly broken down and enough details are articulated for the team to make it part of Sprint.
- Independent - Independent of all other user stories.
- Negotiable - Details on how to complete the story should be left open for a discussion for the developers.
- Valuable - Add value for the business
- Estimable - Estimate to a good approximation, either its too large and needs to be broken down or too vague to be estimated and hence require elaboration.
- Small - To be fit within an iteration or complete in few days to week. Larger requirements tend to be hard to predict.
- Testable - Should be able to test
This will allow developers to breakdown software development to smaller chunks and build the software iteratively with feedback coming in from each of the incremental releases.
This iterative and incremental development practice with the concept of continuous integration changed the landscape of modern software development. Continuous integration leads to Continuous delivery: an approach in which teams ensure that every change to the system is releasable, and that delivering frequently will enable them get faster feedback and hence better features and quality solutions.
By building the capability to rapidly, reliably and repeatedly push out enhancements into a powerful platform, CloudIO is working with leading enterprises to help them move to Continuous Delivery. CloudIO platform helps developers build solutions to its customers at low risk, with minimal manual overhead and no downtime, and can respond to business needs faster and improve satisfaction for end-users. In the coming articles, we will see how a user story can be quickly implemented and put to use for the customer using the @CloudIOPlatform.
