Getting Requirements Right with KickOffs and Desk Checks
Have you ever been at a restaurant and received something different than what you ordered?
I’ve had unwanted sour cream on my nachos and swiss cheese in my omelet instead of provolone. Even if it was close to what I requested, I often returned my food to the kitchen to get it fixed. Waste of time for both me and the cook, not to mention I would be hungry by the time I got my food.
A similar experience has happened to me with software development. As an Agile organization, we regularly hold lead reviews and story grooming sessions. Despite numerous meetings, I sometimes found myself in a situation where what a developer coded is not exactly what I asked for. How is that possible after hours of discussions? The answer is simple. Human nature. What one hears may be interpreted differently by someone else. Memory isn’t always reliable for stories reviewed a few days or weeks before. Also, until a person is the one working on a story, he/she may not be listening 100 percent during team activities.
As any developer and QA engineer can tell you, building something that doesn’t match the requirements requires rework and retesting, which impacts a team’s ability to meet sprint commitment. So how can we minimize wasted time? My department has adopted the following practices which have reduced the botched order syndrome significantly:
- Story Kick-Off
- Story Desk-Check
Story Kick-Off
A story kick-off is done prior to coding to ensure that the developer, QA and the BA/Product Owner are in alignment regarding expectations. Asking the following questions helps to ensure a successful kick-off.
- Are the requirements clear?
As the BA, I review again all assumptions, the acceptance criteria and any supporting documents, such as UI and report mock-ups. Everyone’s memory is refreshed, and the opportunity exists to answer questions and to ensure everyone is on the same page. In addition, the wording within the story may be modified or additional notes added to provide clarity.
- Do we have all the technical tools and information needed to finish this story?
Our developers perform preliminary investigation prior to a kick-off to determine what is needed from a technical aspect. When issues affecting completion of the story are identified, negotiations around requirements commence. For example, we may find that a new function cannot leverage existing code as initially anticipated. I often ask whether the extra effort can be absorbed in the current story without impacting timelines. The outcome may involve conversion of an acceptance criteria into its own story or pulling the story from the sprint altogether for additional refinement.
- Are there any blockers?
We normally identify story dependencies ahead of time and plan sprints accordingly. Due to resource constraints, we sometimes find ourselves playing blocking or dependent tasks within the same sprint. If called out during kick-off, it reminds us to coordinate activities across the team to help ensure timely completion.
- Will assistance be needed from other departments in order to complete coding or testing?
If yes, we like to inform those groups at kick-off, so they have a few days to plan accordingly. As an example, we may need DevOps to bring a connection down to test failure scenarios.
Story Desk-Check
A story desk-check is performed when coding is completed but not yet pushed to a test environment. The participants include the same people involved with the initial kick-off. Activities include the following:
- The developer demos the functionality that he/she has built while cross-checking against the requirements of the story.
Have all the acceptance criteria been met? Does the output, such as UI screens or reports, match the mock-ups? Are any bugs encountered during the demo? If identified at that time, the developer can more easily fix issues in their local environment before it even gets to QA. Problems found sooner contributes to less bug finding during testing which equates to time saved.
- Provides the opportunity to tweak a requirement.
A demo sometimes identifies requirements which sound good in theory but does not work well in reality. For example, we may find that an error message that I’ve requested is hard to see. I could ask that the error be moved to a more prominent location or be highlighted in red. If the impact to the sprint is small, the developer and QA can agree to the modification and the story is updated. For larger efforts, I create a new story to be placed in the backlog and prioritized.
- Helps QA prepare for test execution.
The developer provides input on how a story can be tested. Are there tools available to help them verify the data? What configuration or setup is needed prior to testing? Impact to existing functionality is also called out so that they can be retested to ensure nothing is broken by the new code.
- Other groups participating in the desk-check, such as DevOPs, become aware of when their assistance will be needed and can schedule their time with QA.
Two years after initial implementation, kick-offs and desk-checks continue to be an important part of our development process. It is extremely satisfying to see how minutes invested up front saves us from hours of rework later. There’s always room for improvement, but in the meantime, I am happy to say that what development now gives me is usually exactly what I ordered!