A scrum master, helping another team, needed some help in restructering the teams’ working process, “bring the process to the next level”.
So: What is the process? Define the next level! With my devilish grin… Starting with my favourite question:
What is the actual problem to be solved?
Most of the time this will open a discussion leading to the core problems. Turns out that most of the team members are contracted via a third party and therefor plan their work in, billable, hours. So this strengthens working in silos based on knowledge, being most productive and efficient.
On top of this the product owner and the QA’s don’t have an oversight on stories being delivered, while every task is being finalized on its own. Apart from that, how to deal with the teams velocity to make the outcome more predictable, on the longer term? Velocity being a metic on functional-/product level and not techniques or expertise.
So we planned the following appraoch:
- The product owner will prepare one E2E-story for the team to learn to break it down in technical tasks, all related to that user story.
- This will be done as an experiment to learn in the next sprint how it actually works.
- Secondly as part of the workshop a relative estimating game will be hosted to show what other components then only time are part of an estimate.
- Using Mike Cohn’s SPIDR-technique we will experiment to write even smaller user stories. Driven on functionality and not the underlying techniques.
More will follow after the workshop