The next step in the evolution of Agile project management

In this blog, I make a case for what I think is the next step in the evolution of Agile project management. The focus of project management used to be based on managing Tasks that people perform to deliver a piece of software. Agile project management shifted focus to managing the delivery of Features. I believe that the time is ripe for the Agile community to take the next step: move towards Value driven project management.
Read more β†’

Effective Retrospectives & Reviews

In my experience as a Scrum trainer and coach, I have seen too many Scrum teams that fail to do what Scrum was invented for: Inspect and Adapt.

Do the following statements describe the situation of your team?
- Little is done about problems discussed in Retrospectives.
- Sprint Reviews have no impact on what is build in subsequent sprints.

If so, you may be interested to read my article on the Scrum Alliance website: Effective Retrospectives & Reviews.

Tips for ScrumMasters: How to act on retrospective outcomes


In my previous blog, I talked about when to estimate user stories so that a Product Owner can do release planning based on velocity and relative estimates. This time, I will discuss another topic that I see many Scrum teams struggle with: how to implement improvements based on what is discussed in retrospectives.

Many Scrum teams have a hard time to continuously improve themselves. In retrospectives, problems and possible improvements are discussed. Then nothing happens. In later retrospectives, the same problems are discussed without noticeable changes. Retrospectives like this are a waste of time. Even worse, missing out on the opportunity to continuously improve is a big waste in itself. The velocity of such teams and the quality of their deliverables will almost certainly get better if they find ways to act on improvements that are identified in retrospectives.
Read more β†’

Tips for ScrumMasters: Estimate user stories outside Sprint Planning Meetings

One of the biggest strengths of Scrum is that it is a framework instead of a detailed methodology such as RUP. In Scrum, concepts are described that make essential aspects of projects fall into place in a very powerful way. One does not need a Process Engineer to tailor Scrum before it can be applied successfully. However, because there are many things that Scrum does not describe in detail, there is plenty of room left to mess things up πŸ™‚

In this blog, I discuss on how to facilitate the estimation of Product Backlog items so that the Product Owner can do release planning.
Read more β†’

Visualizing user stories from idea to production

In many Scrum projects, user stories that are Done at the end of a sprint have not yet been put into production. In other words, production is often not part of the Definition of Done. There can be several reasons for this. Examples are:

  • additional acceptance or integration testing is needed that can not (yet) be done within the sprint;
  • user stories have dependencies on hardware of software from an external party that is not yet available;
  • minimal marketable features are bigger than what can be produced in one sprint.

Read more β†’

Estimating a product backlog more effectively

Ever since I read Mike Cohn's book Agile Estimating and Planning, it has been a great help in doing Agile projects. One of the ideas that I like very much is to estimate user stories on a product backlog in an abstract measure: story points. Story point estimates only need to be correct relative to each other. Having such estimates allow you to monitor velocity: how many story points can be done in an iteration. Based on velocity and an estimated product backlog, decisions about scope, schedule and budget can be made and continuously refined a very informed way.

The most common way to estimate user stories on a product backlog is by doing a planning poker session. However, in my experience it is pretty hard for a team to do this effectively for a big list of user stories. Therefore I tried out another approach.
Read more β†’