All roads lead to Rome, but with Scrum it is faster.
Those who have decided to make the switch and take the first steps will not have it easy at the beginning. Here we give a little help to get started, so that Scrum runs easier and smoother for you, too.
With these two tips your retrospective and sprint planning will be more successful.
1. Retrospective
For the retrospective, the following procedure has proven successful: at the beginning of the event, each member of the Scrum team receives post-its and a pen. All positively and negatively perceived things during the last Sprint are noted on them. Each member then briefly presents the points and sticks the post-its on a whiteboard. When all members have listed their points, the post-its are sorted thematically. In most cases, the number of posts alone indicates which topic should have the highest priority. So the more post-its on a topic, the more important that topic is. Then, from the highest to the lowest priority, each topic is systematically discussed. Suggestions for improvement are recorded in writing and at least one of the suggestions for improvement flows directly into the next Sprint and is recorded in the Sprint Backlog.
The following questions are Scrum standard:
- What did we do so well that we need to talk about it straight away, before we forget?
- What did we learn?
- What do we need to do differently in the future?
- What have we not yet understood?
If you want to make the retrospective even lighter or more playful, there are countless ways to do it. For example, a starfish is drawn on the whiteboard by the Scrum Master. The questions are written on the starfish’s arms and then the post-its are sorted into the questions.
- What went well, what do we need to continue?
- What activity do we need to intensify?
- What activity do we need to curb?
- Which new idea do we have to take up immediately?
- What went less well, what do we need to let go?
2. Sprint planning
To estimate stories, tasks, and bugs from the Product Backlog during Sprint Planning, we recommend the following for the Planning Poker. Use existing estimated tasks as a reference for your story point estimate. If it is the first Sprint, it might make sense not to provide an estimate in this Sprint. But in the second Sprint, Story Points could be assigned to a Story from the first Sprint. This can then be used as a reference for estimating the stories from the second sprint.
Make sure that the estimation of the activities is the sole responsibility of the development team. Neither the Product Owner nor the Scrum Master are allowed to interfere in this estimation. If they do interfere, it can lead to tasks not being completed in a Sprint, i.e., being underestimated.
Experience shows that it is always better to give a conservative estimate rather than a positive one. Even if processes seem to have been discussed in detail, they often turn out to be unpredictable.
If many underestimated processes come together in one Sprint, the Sprint degenerates into stress for the developers, which leads to errors and unclean work, or simply to stories that cannot be completed.
kununu