Definition of Done

Our author Faisal Mahmood discusses "Definition of Done" in this article. A clear "Definition of Done" is very important for success of the Sprint and should be visible to all stakeholders in the team.

"The Sprint has just ended. The team has completed a lot of work and they feel comfortable going into the review meeting. The Product Owner has been working with the team, although not on consistent basis, but the collaboration is getting better. The team has been asking quite a few questions and the Product Owner was able to answer most of those questions during the Sprint. The Product Owner has felt that the team has made good progress. The Definition of Done has been agreed a few Sprints ago and it’s been visible. The team has been keen to complete all the work according to the Definition of Done.

The review meetings kicks off. The team and the Product Owner discuss the work completed during the Sprint. The discussion is lively. The Product Owner looks excited. She starts to discuss about the release schedule and the road ahead.

The Product Owner asks enthusiastically, when can we ship? Suddenly, the mood starts to change. The comfort level goes down. Team starts to get edgy and Product Owner starts to get irritated. According to the team, they have completed the work according to their Definition of Done. But, it’s still not ready to be shipped. Further work is needed.

The Product Owner is confused and frustrated. She thought the work was done and ready to be shipped. The team explained what was already completed, and what remains to be done. Later it turns out, the team would require another three Sprints to complete all work to make the product increment shippable. Ouch!"

You can find the rest of the article here

How to become a great Product Owner?

Our author Faisal Mahmood discusses becoming a great Product Owner. Product Owner is a key role in Scrum framework. He gives the highlights in this article about this role.

"Of all three Scrum roles, the Product Owner is by far the most misunderstood role. What’s the core responsibility of the Product Owner? The typical answers that come out are
  • Product Owner tells the what team what to do
  • Product Owner defines the product and the Product Backlog
  • Product Owner clarifies the vision
Well, these are all valid activities that the Product Owner needs to carry out. The Product Owner role is associated with creating user stories, providing the team with the acceptance criteria, providing feedback in the review meetings. On top of all this, better Product Owners try to work with the team during the Sprints. But the key aspect of the Product Owner role is often forgotten.

The core responsibility of a Product Owner is to maximize value. If there’s one thing the Product Owner must do, that is to maximize product value."

You can find the rest of the article here

Sprint Zero - A Tool To Hide Waterfall Legacy

"Sprint zero is widely used antipattern to hide bigger and uglier issues. People using Sprint zero state different reasons for using Sprint zero. Some of the very common reasons include
  1. We don’t have a plan yet
  2. We don’t have a Product backlog
  3. We need to get a handle on architecture and design
We don’t have a plan yet
People are used to having a project plan outlining all the details. They think they ‘need’ these details to get started. People using Sprint Zero provide various combinations of reasons including the need to figure out schedule, deliverable, risks, assumptions, dependencies, resource plan and other such artifacts.

A heavy upfront planning phase is one of the biggest legacy of waterfall process. Having a plan calms nerves. It provides people with an illusion of control. They feel like they know what they are doing.
In Scrum, we do plan. However, we don’t spend a whole ‘Sprint’ or more just planning. We plan, we act and we adjust our plans as we move forward. This ‘thin’ planning upsets people. They get scared. They no longer have that ‘illusion of control’.

This fear leads to Sprint zero. During Sprint zero, they can ‘plan’. They can do almost all the things done at the start of a waterfall project while ‘doing Scrum’."

You can find the rest of the article here