the AgileBlog for AgileSkills
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.
Is there a planning meeting in Kanban? While development teams often think, that using a task board and doing Kanban are the same, that’s not true. Kanban is a system which is highly focused on core metrics, and of course work and delivery is planned in Kanban organizations. This article explains how work can be planned and organized with Kanban cadences.
Where to find your next task in a pull system? Though, the answer to this question seems simple at first glance, human beings often times tend to choose the task with the biggest fun factor. This article shows why it makes sense to select the task according to specific criteria.
What do the story point values mean? This is a question that people ask themselves very often when participating in planning poker. This article shows how we can get intuitive access to agile estimation techniques with the help of visual support.
A beginner’s guide to story mapping answers the questions many organizations ask about agile transitions. Where do our requirements come from? How should our teams be structured? In what form do we deliver our product and what value does it deliver to the customer? Story mapping can provide answers to all of these questions.
Many authors consider technical debt and bugs identical and equate the reduction of bugs with the repayment of technical debt. Unfortunately, this is wrong. This article explains the characteristics of technical debt and bugs, and why it is important to differentiate.
Agile purists often believe that there are exactly two types of requirements in an agile organization – epics and user stories. In this article I explain why it makes sense to look at technical stories in addition to user stories.
Story points are superior to effort estimations. Nevertheless, classic effort estimations are still part of day-to-day business in many companies. In agile companies, they have been replaced by complexity estimates with story points. Read now, why this makes sense!
The Fibonacci sequence and the Cone of Uncertainty are two concepts which repeatedly appear in agile development and aim to the very heart of agile estimation techniques. This article is going to tell you why this the case and where both concepts originate from.
Often newly certified Scrum Masters or beginners in the field of Scrum wonder how a retrospective is actually conducted. This article gives a short introduction to the execution of Scrum retrospectives.
Do you have any questions about agile transitions, would you like to train your employees, or be accompanied by us in a transition project? Send us a message!