And we came to the end of yet another Sprint , the team struggled a lot, but the end result was not as expected.
Everyone was engaged, had a clear knowledge of what needed to be done, had no blockers …
And get to the retrospective meeting and almost unanimous opinion of the main reason for the delay:
– We have too much meetings!
At the beginning of the project it is common to have more meetings, especially in geographically separated teams, the problem is not to let it get in the way.
The main reason is that in the Planning phase hours spent in meetings are ignored, either by assuming that this will not be a blocker to development, or simply by not having the faintest idea how much time it will take to separate from Sprint all for that.
To solve this problem, which is not that common, but certainly exists in many projects, my suggestion is to adopt the meeting burnup chart !
How does it work ?
Well, we’re familiar with the burndownn chart and burnup chart, with Sprint points to know the progress of the team:
So the strategy is the same as counting points for a task, then let’s count the points (hours) of meetings:
- meetings go on for half an hour or more should be considered;
- the account is always multiplied by the number of participants (6 people in a half-hour meeting = 3 hours);
- the values increase incrementally in the graph;
- daily meeting usually does not enter the account, only if takes more than half an hour;
- to leave no doubt:pair programming does not count!
Once you have the information at the end of Sprint, it will definitely help you get better planning in the next Sprint!
Let’s go for an example …
Team em>: 5 devs – 1 scrum master – 1 product owner
Sprint size em>: 2 weeks
– 5 with 3 devs of 1 hour = 15 hours
– 5 with all 1 hour devs = 25 hours
total sprint: 40 hours.
project total: 40 hours.
– 10 with 3 devs of 1 hour = 30 hours
– 5 with all devs from 3 hours = 75 hours
total sprint: 105 hours.
project total: 145 hours.
The graph below represents the meeting burnup chart of these sprints:
Notice how by visualizing in a chart that feeling of meeting too much becomes a mathematically an undeniable fact that needs to be reviewed and considered for upcoming sprints.
Hope this idea helps you, good luck!
Fernando Boaglio, for the community