In an earlier article, my fellow colleague and PBS-Blogger described the way user stories are handled and closed in our team. If you want to refresh your memory, check out the article published on 11.11.2016. The piece describes the life cycle of our user stories from start to finish: they go from Draft to Specified to then become Documented and Tested and finally get Closed. During its journey, a story passes many quality gates. In this particular article I would like to highlight these milestones and the way we hold our work and ourselves to a high standard.
Definition of Ready (Specified)
Before a user story is planned and committed to in a sprint we make sure that the team is ready to start working on it. To be certain that this is the case a couple of key factors must be known and specified.
The user journey has to be defined and necessary mockups or wireframes must be available. This is necessary so that every team member has an idea of how the thing that will be developed is going to look like. Without a representation in the real world, mental images of the same thing can vary wildly.
A story must have clearly defined acceptance criteria which have been discussed by the team and all dependencies to other teams or other services have to be identified. Only then it is possible to figure out which implementation steps are needed to implement the story. That also means that we have an idea on how we are going to test the functionality. This then enables to team put a point estimation on a story and ensure that it is small enough the be done in one sprint.
A story “owner” is identified within the team. This means that there is a main contact point within the team to direct questions to. When any design or implementation question pops up it is this person’s job to do some research or contact the sponsor and/or other experts who can help find a solution.
Definition of Documented
When that solution has been found and implemented, a few things must be true for that particular story to move to its next life stage.
Firstly, all code has to be checked in and tested on an actual demo device (and not just the machine of that particular developer). The code also has to be covered by automated tests and reviewed by a peer. Two sets of eyes: one automated, the other physical.
The developer has to leave a note on what build is containing the implemented changes and also leave documentation on what configuration or settings are needed to enable and configure the functionality. This includes any information on how to test the feature.
Definition of Tested
During the testing process, our testers open up test cases and tasks in which they thoroughly examine the implemented functionality.
All test results must be documented and include the data which is necessary for the team to keep track of testing conditions. The necessary data points include things like software version, hardware setup, versions of depending services et cetera.
The configuration to review the functionality has to be configured on a review machine and if there is an integration test coming up for a feature, test cases should be added to the integration test list if available.
Definition of Done (Closed)
After all these steps have been taken it is surprisingly easy to cross the finish line. As my colleague described in his article, the team evaluates together whether we think whether the acceptance criteria of the story are fulfilled or not. When we deem the functionality to be implemented to satisfaction, the story gets its stamp of approval. When we find that there is something missing, the story gets pushed to a previous stage.
Processes: Flexibility vs. Rigidity
There are voices that say that these kinds of processes and quality gates work against the principles of agile. While it is true that the agile manifesto values “Individuals and interactions over processes and tools” this does not mean that they have to be discredited and taken out of the equation completely. I find that respecting and enforcing processes which have been set up collaboratively make things go much smoother than relying on your own ability to somehow get it right by yourself.
I believe however that rigidly adhering to any rule or process is a way to quickly set yourself on the fast track to rob yourself and your team of ingenuity and flexibility. Adaptability is a key factor of being successful. That is why my team continuously evaluates these definitions to add things that we’ve missed and weed out the stuff we don’t need after all.
So here’s my two cents on the subject: respect your process and the way you have set up your working environment but don’t be afraid to change things up when necessary.
What do you think?
How have you set up your processes? That one time you had to disregard them completely – how did things go? I’d really like to know, so don’t hesitate to write a comment or send an email and let’s talk about it!