As a Business Analyst in a company utilizing an Agile development methodology with a high release-to-market approach, it has become truly evident and apparent that user stories are powerful tools in the software delivery process. Conjuring on average about 3 to 5 user stories on a good day, the practice of creating, communicating and processing user stories has become second nature. However, I face the constant challenge of ensuring the acceptance criteria, which should meet both the needs and requirements of the development and quality assurance team, is at an above-adequate level to ensure that efficiency is optimized—and lead time from concept inception to delivery is minimized.
In this endeavour, I typically aim to follow the below guidelines when not only writing good user stories, but also kicking-off the development process.
Abide by INVEST guidelines
The user stories you create should be:
I – Independent.
Ensure that user stories can be worked on independently of each other.
N – Negotiable.
The relevant parties (BAs, Developers, QAs and users) ought to discuss the deliverable outcome of the user story.
V – Valuable.
A user story ought to hold business value and contribute to the ‘worth’ of the overall organization.
E – Estimable.
Should be estimable in size such that prioritization activities can be carried out correctly and accurately.
S – Small.
Follow the 3-4 days delivery period when creating user stories.
T – Testable.
Before the user story can be considered ‘done’, it needs to be tested, either by the QA team, or by other relevant parties, depending on the situation at hand.
Create stories in a collaborative fashion
In a previous blog post of mine, I emphasized the importance of collaborative requirement elicitation. This is a necessity when creating accurate and productivity-enhancing user stories. No one can be an expert in everything, however, by using the various resources available to you in the organization, you can ensure that expert knowledge and instruction is included in your user stories. To implement the above has been a trial and error process. Initially, I was creating user stories with little involvement from developers and testers, which led to inefficiencies during the development and testing of the user story. Now I follow this approach:
i – Conjure the user story and desired acceptance criteria.
ii – Lead a meeting session with senior developers and testers to introduce the team to the concept at hand.
iii – Obtain feedback and input from developers and testers as to ensure their requirements are satisfied.
iv – Amend the user story accordingly.
Although severely simple in nature, the above approach has led to noticeable increase in productivity. Reasons being,
i – It introduces the concept and objective early on in the process (before entering the Kanban backlog).
ii – It allows for the communication of the overall business objective.
iii – It allows for any misunderstanding and confusion to be dealt with early on in the process.
iv – Enables the identification of the most optimal manner to achieve the task at hand.
v – Obtains team wide commitment and accountability.
Acceptance Criteria MUST be concise
Because you are introducing new features to the system, there is a definite probability that misunderstanding/ misperception may persist by the development and testing teams. Although the collaborative approach mentioned above alleviates some of this, it is usually carried out with senior members of the teams. The development and testing of the user story itself, can be done by other members, thus having clear, concise and unambiguous acceptance criteria is needed. Doing so, also minimizes the chances that ‘out-of-scope’ testing occurs and the time taken to achieve the state of being ‘done’ is lessened.
There are of course many more complexities to ensuring that productivity in the Product Engineering teams is optimized, however, the user story plays a pivotal part in this. Ensuring that the user story holds enough detail and specificity with little ambiguity is a great starting point. This is greatly necessitated for not only the more complex and technical user stories, but also for the more mundane and simple user stories. Having a clear understanding of the business/user objective, having a clear defined scope, knowing exactly what is required, ensure that any member tasked with completing the user story can do so in a more efficient, effective and well-organised manner.
