An inherent challenge in software development is making sure that the software delivers what customers really need, not what we as a development team (or they!) think they need. It sounds simple enough, but in reality many requirements get lost in translation, or we jump to solutions without even understanding what the problem was in the first place.
One way that we try to tackle this at Mobenzi is through “user stories”. User stories are an Agile way of capturing requirements from a user’s perspective, but can add value regardless of your methodology. Essentially a user story is made up of a description and acceptance criteria:
“As a <WHO>, I want to <WHAT> so that <WHY>”
- Identifying all the envisaged system users (the WHOs) upfront is good way to start scoping, e.g. “Fieldworker”, “Data Analyst”, etc.
- The WHAT is the need, not the solution, e.g. “submit my form” (need) vs. “click a button” (solution). The solutions comes later during design.
- The WHY is surprisingly important. If the need can’t be justified, is the requirement really so important? For example, “…so that the survey responses I’ve captured on my mobile device can be viewed on the web by the project data analyst”.
The conditions the system must satisfy to be accepted by the end-user.
- They define the scope of the story.
- They form a checklist that can be used by the developers, testers, and customers to verify that the functionality works as expected.
- Examples:, “A form can only be submitted once all required fields have been captured”, “The form data is only uploaded if/once there is data connectivity, otherwise remains pending upload”, “Once submitted, the form is removed from the handset”, etc.
User Stories at Mobenzi
At Mobenzi, we use user stories throughout our systems development life-cycle – from strategic planning to delivery:
Product Roadmap planning
Each feature on our Product Roadmap has a handful of “Epic” (high-level) user stories. These stories help us to both prioritise the feature (why is it important and to whom?) and set a rough scope for budgeting and planning.
Once a feature has bubbled near the top of the backlog, it needs some detailed requirements gathering, and each Epic story needs to be broken down into many more granular stories. Workshopping requirements from each user’s perspective with project stakeholders helps to cover all angles and avoid getting bogged down with premature solution ideas.
…each Epic story needs to be broken down into many more granular stories.
Stories can be prioritised (e.g. “must-haves” vs. “nice-to-haves”) and should be easy to reorder. Traditional Scrum theory advocates writing stories on physical cards that can be stuck on a board, but some people capture stories into spreadsheets. At Mobenzi, we use Trello.
Ideally, the project stakeholders should validate any assumptions and sign-off the acceptance criteria as part of this phase.
With our user story requirements in hand, we know WHAT to do, but the HOW is determined during the design phase. For design, the user story acceptance criteria inform the screen designs and the more detailed business rules, which can in turn be validated against the initial stories.
At this point, we augment our initial story cards with mock-ups, diagrams, technical assumptions, and any other related documentation that a developer would need to implement the user story.
During sprint planning, when we’re reviewing our user stories with the development team, the acceptance criteria are a key indication of scope that inform the development estimates. The developers can split stories up further where it makes sense for implementation, and add their own “technical acceptance criteria”. During development itself, the acceptance criteria become the checklist for the developer to know when something is “done” (and to avoid scope creep).
The user stories form the base of our Quality Assurance (QA) test cases (with minimal additional preparation). However, caution is advised: The existing acceptance criteria are not the be-all and end-all for testing, as they typically don’t cover exception scenarios or negative testing requirements. It can also be misleading to test stories in isolation, so end-to-end exploratory testing is another vital step.
User Acceptance Testing
Be it with internal or client stakeholders, getting “sign-off” on a delivered feature can be tricky. When stakeholders see something working for the first time, new thoughts and opinions inevitably rise to the surface.
When stakeholders see something working for the first time, new thoughts and opinions inevitably rise to the surface.
Having the “That wasn’t part of the scope (but we can add it to the backlog).” conversation is certainly easier when those stakeholders were involved upfront in the user story and acceptance criteria definitions, as well as the prioritisation. The Acceptance Criteria can also be used as a predefined “test pack” that stakeholders can run through to be sure they’ve covered everything.
Ultimately, user stories are just another tool in the analysis toolbox, but not the silver bullet for getting things right. They can, however, help with stakeholder engagement and the minimisation of duplicate effort between the phases.