Many Scrum teams handle the Scrum Events rather out of habit or even mechanically. These events are often insufficiently prepared or poorly executed. This article describes the inputs and outputs of the five Scrum Events. Find out what is needed for each event, what it should deliver and what value it adds to your team.
Not all job advertisements for Scrum Masters describe the activities of a Scrum Master correctly. One common mistake concerns the description of the Scrum Master as the person responsible for the implementation and execution of the “Scrum process”. This article explains why Scrum is not a process and how the development process of a company can be embedded in Scrum.
Whenever I introduce Scrum teams to Planning Poker, one simple question arises. Why are some problems estimated with the same Story Point value, although they seem to have completely different characteristics? This article explains why it is not meaningful to compare tasks with the same Story Point value to each other, and how Story Points group problems into orders of magnitude.
More often than you would like to see it, teams struggle to craft a proper Sprint Goal. As a workaround, teams use generic Sprint Goals which they tend to fail. This article gives an overview of what a Sprint Goal is, what it is good for, and hence, why Sprint Goals are Mandatory.
A little while ago someone asked me the question how to conduct lessons learned workshops in a Scrum team. They wanted to change their organization from classical project management to Scrum and could not answer this question. This article explains the different feedback loops of Scrum and how they replace the classic Lessons Learned workshops in agile teams.
The relationship between story points and human perception is a really interesting topic. In the strict sense, the question at hand is why we use a representation of Fibonacci’s sequence when we are estimating the complexity of tasks in agile teams. Why do we use Story Points, and what makes Story Points a better tool than other estimation techniques? Those are the questions answered in this article.
Many Scrum teams have a task board in their workspace on which they visualize their tasks and requirements. These boards often show the states “ToDo”, “Doing” and “Done”. The use of these terms as part of the development process is not wrong, but in the environment of Scrum they have a different meaning. This article explains the relationship between ToDo, Doing, Done and the three Scrum artifacts.
Job postings for Scrum Masters, Agile Coaches or Agile Leaders all have one requirement in common. It is always part of the job to train and support an agile mindset in the team, the organization or the company. But what does it actually mean to have an agile mindset, and why is it so difficult to establish an agile mindset at all?
A beginners guide to Planning Poker explains the why, how and what of this agile estimation technique. As classical effort estimations don’t work very well, many teams are using Planning Poker to create the estimates. But, why do we actually do this? How do we do this? What has to be considered when using planning poker? This article gives an overview and explanations regarding agile estimations with Planning Poker.