During a retrospective, I realized that the two internal customers of the team are not used to write epics and user stories, whereas the developers have some experience but still in some areas little business knowledge. Often ambiguous or unclear specifications hindered the team to start working.
Thinking of Pair Programming as an instrument to spread knowledge, to increase quality and structure, and to promote collaboration, the idea of applying similar practices to the creation of specifications appeared to be helpful.
- Development team consists of 5 developers (nice mix of work experience)
- Two internal customers, one of them as Product Owner
- Team applies Kanban (started some months ago)
- Whenever new features need to be specified, the internal customer “pairs” with a “random” developer. Over the time, every internal customer should have paired with every developer.
- The developer brings in his knowledge and experience in writing epics and user stories.
- The internal customer brings in the business expertise.
- Like in Pair Programming, the work is done collaboratively.
The expected benefits:
- Internal customers and developers get to know each other better through collaboration.
- Knowledge is transferred in both directions.
- The results (epics and stories) are already reviewed and potentially “Ready to start”.
- Developers will better understand the business reason of a feature and the prioritization.
- Developers can bring in their ideas in an early phase.
Overall, this approach seems to be worth to be tested with a small number of teams.
How do you think about this?