Your first Scrum meeting can challenging especially if you never had a Scrum training.
Read More
The First Scrum Meeting
Meeting Types
I spend quite some time at work in meetings. So I thought to I try to identify the different types of meetings I am facing.
Meeting Type 1. The lonely meeting
The meeting were no one but you is arriving. You are wondering: Have you missed the meeting cancellation, does no one care, has outlook messed up the time zones again ……
Meeting Type 2: The laptop meeting
The meeting where everyone seems to be more interested in their laptops (doing other work or surfing the internet), instead of paying attention to the meeting.
Meeting Type 3: The no one cares meeting
At this meeting no one participates. The meeting is so pointless that even the meeting host will not arrive.
Meeting Type 4: The perfect meeting
Everyone arrives in good time. The technic is working without problems. Everyone is concentrated. The presentation is interesting ……. (It must be a dream).
Meeting Type 5: The “Death by Power Point” meeting
Be alerted when you hear the words “I have prepared a little power point presentation”.
Days vs. Story Point Estimation
I would like to share some of my thoughts about story point estimation.
I am working as a product owner with two scrum teams. One team is estimating the product backlog in story points, the other is using days. When we do sprint planning (two week sprints), the teams split the user stories into tasks and estimates them in hours.
Comparing both teams I experience that the story point estimation of the backlog is much easier for the team. It took some while to get used to it but now estimation is very straight forward with good enough accuracy for release planning. It’s easier because we estimate how “big” a user story is, not how long it will take to implement it.
Scrum Days vs StoryPoints Estimation
On a product owner course with Mike Cohn he had a very good way to describe the difference between days and story points:
Think about two different persons, one a very sporty guy and the other a normal guy. Now you ask these two persons how long it will take them to run to the building you can see not so far away. The sporty guy answers 5 minutes, the other answers 10 minutes. It will be very hard for them to agree on an estimation. If you ask them instead how far away the building is, you probably get two answers that are quite close together e.g. 1000m and 1200m. They both will be able to agree.
This is exact the same situation for developers if you ask them how long a user story will take to be implemented. The team will come up with different estimates based on their different experience levels. If you instead start estimating how “big” a user story is it will be much easier for the whole team to estimate. There will be much less discussion and the whole process will be much faster. After some estimate sessions everyone in the team will get a good felling for what “big” means.
Recent Comments