This is not entirely only my idea, originally it comes in collaboration with Hannes Kockro, a scrum master I had a chance to work closely in the last 2 years.
There is one variable which is true for every scrum agile team setup: “Time cannot be shrunk or stretch”. All the other things can be changed and adopted in order to make our scrum experience better or worse. If we concentrate on improving, every scrum master will give us three recommendations or guidelines based almost purely on empirical data.
This is the most common recommendations:
- The team should probably consist of 5 to 9 people.
- Timeframe for sprint should be one, two or maximum three weeks, while 90% of scrum teams doing it in 2 weeks interactions
- The team has daily meetings, and sprint retrospective/review meetings at the end of each sprint interactions.
Ideal scenario
Idea behind is to fix timeframe, allocate people and execute a plan for one sprint period. Ideally, after one sprint period team gather and conclude that they achieved all goals. (figure 1)
Realistic scenario
In the non-ideal world, during the sprint team has obstacles, issues, uncertainty, unpredictable behaviors of the component they do not have a control on. All of this lead to more realistic expectations of a scrum team, which allows a tolerance of +/- 20% of planned complexity (figure 2).
Just established team
Everyone who ever tries to establish a new scrum team, or add/subtract multiple team member, faces the very same issue, the team can’t even achieve +/- 50% of accuracy. Freshly established scrum team have a lot of “unknowns”, team member do not know each other, the product itself is unknown or some team members have still very little knowledge of it.
What is initially happen is high fluctuation which goes all over from +/- 100% of accuracy for the first couple of sprints, and then it starts to stabilize around the +/- 20% belt (figure 3).
Basically, on figure 3 we see, that team struggled first 10 sprints to understand and take in consideration their own capacity. After that period everything starts to stabilize inside +/- 20% belt (from 80% to 120% in this case).
Solution
By looking at this image it is not hard to understand that for the accurate and predictable team we need 10 sprints which length is usually 2 weeks, which gives us 2~3 months for the team to establish.
With every interaction, the team had a chance to sit together and discuss what went wrong, what they did good, propose something new and trying out. And that is the major thing which brings the team to better accuracy. With every retrospective, the team gets closer and closer to their desired accuracy.
Not every retrospective brings a golden solution, or make a “click” for everybody in the team, but every time, the team tries, with or without success. And finally, after 3 months (10 sprints) they can call themselves predictable.
But there are still variables in this equation, which we can adjust in order to get the desired outcome faster. If we saw that team need 10 sprints to establish, why not change the duration of the sprint for one week, instead of two? Figure 4 is a chart of the velocity for the same amount of time (30 weeks) like figures above, with the difference that first 10 sprints was one week framed (colored yellow), while others were 2 weeks.
With pushing the team every time into retrospectives while they still glue together, you create a room for constant improvement on a weekly basis, nobody has to wait 2 weeks to ignite some topic, a team member can try out new methods with less worry for failure.
Conclusion
Therefore, the conclusion can be that, if you struggle to operate through big team change, or just formed a new team, give this method a try and you will see that you can speed up team glue just by repeating interactions. The new team member does not know each other well, retrospectives helping them to connect, feel each other, understands others pain.
Top comments (3)
Thanks @damnjan for writing.
In theory I would agree with shorten the sprint length.
But in my experience this brings a lot of overhead for having sprint review/retro/planning on a weekly basis.
And this requires a backlog containing many small items, as more complex stories tend to be not finished within one week.
Hi Erik,
Thank you for your reply :)
Yes, I remember we had an issue with ticket size, not necessarily because they were too big for the sprint, then because people tend to overestimate all the time. I guess that was due to the fact that most of the developers are set to two weeks sprints.
I’m curious about how long your team tried one-week sprints?
Cheers
We tried it only for three or four weeks. Then we ran out of small stories and the PO and the team were tired of splitting up bigger ones.
Then we switched back to two weeks. And as you said, over time the waves settled and we found our velocity .. only to get a new team member and to start over again :D