One of the many new practices for organizations going through agile transformation is the move from requirement documents to user stories. I’m quoting from Mike Cohn *:
“User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.”
In the classical approach, there is a requirement document that has been agreed by development and business groups after multiple time-consuming iterations. Even if both parties agree on a document after significant time and start developing the new feature, chances are part of the original scope gets obsolete or changes and things need to be reiterated and perhaps portion of the development efforts have been wasted. This approach is obviously not suitable particularly for time-critical projects. On the other hand, user stories are mutually understandable both for customers and developers and increase the communications between team members and stakeholders. User stories also allow the development team do the practical planning. As Roman Pinchler nicely puts it **:
“User stories are not about documenting requirements; they want to enable you to move fast and develop software as quickly as possible;not to impose any overhead.”
As a general practice, as a team, we also adopted following “user story” approach instead of classical IEEE Standard 830 “The system shall.. ” type of approach. We intend to start first with Epics (relatively large story) that is typically broken into several user stories over time. They may not be brought to ‘Done’ state in a single iteration and likely continue several Sprints by getting evolved constantly based on the customer’s feedback to the early and frequent deliveries. Since there are different type of subscribers in our ecosystem and the business rules are changing from one to another we heavily benefit Persona’s. A few of the user stories in our Product Backlog are:
- As a X type of subscriber, I want to subscribe to a movie package via Carrier Billing so that I make the payment together with my mobile data fee.
- As a Y type of subscriber, I want to cancel my subscription via Apple Store so that I can re-subscribe via web portal
- As a Z type of subscriber, I want that Turkcell recognizes me so that I can login without entering any password
There is also another benefit of user stories. User stories are smoothly translated to test cases coupled with the acceptance criteria. It reduces the risk of missing test scenarios and as a result increases the quality of software.
As a downside, as we are a team developing software for back-end services, from time to time the dev team have some difficulties to estimate the SP for a user story that is leveraging on a blended web service structure. It’s challenging to assign the relevant SP to that particular fuzzy user story even if the overall SP estimation to the collection of user stories is definitive .