Sprint Planning

Someone may say that planning in Agile is not as important as it is in classic management approaches. But this is a very false assumption. Planning in any of the Agile Frameworks, and for sure in Scrum, is as important as it is in Waterfall. The only and main difference is the horizon for which we plan. In classic management approaches, we are planning the whole project upfront. In Scrum, in details, we are planning only one interaction (or a next 24 hours when it comes to the Daily Scrum, but this is another subject).

Continue reading Sprint Planning

White Elephant Sizing Game

White Elephant Sizing Game is an estimation technique which is inspired by White Elephant Gift Exchange, Dirty Santa and/or Yankee Swap. The goal of this game is to estimate a significant number of Product Backlog Items in a relatively short time.

There are significant difference between White Elephant Sizing Game and Planing Poker. You need to review which one is better for you team. From my experience White Elephant Sizing Game is better in case there are more PBIs to estimate/size.

Continue reading White Elephant Sizing Game

Sprint Retrospective for Scaled Scrum

Retrospective plays a significant role in any of the Agile frameworks. One of the Twelve Principles published with Agile Manifesto says:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Retrospective enables the Development Team to focus on self-improvement. The basic recipe for this event is quite simple: (1) review what has happened in the last iteration, (2) plan action to improve what can be improved and preserve what if worth to be preserved, (3) try to carry on with this plan in the upcoming iteration.

Things become a bit more complicated when we are in the environment where more than one Development Team are involved (Let’s assume we have three teams or more). Why?

Continue reading Sprint Retrospective for Scaled Scrum

Planning Poker

Planning Poker, also known as Scrum Poker, is one of the most popular estimation technique used in Agile. It’s used to estimate the relative effort (in most cases) of the Product Backlog Items. There are two main reasons for which this method has been created:  (1) to optimise time needed to provide an estimation while (2) allowing all team members take part in it.

Continue reading Planning Poker

Root Cause Analysis

Despite our best efforts from time to time it might happen that application we have build crash. Once it happens, we do our best to restore broken functionality (or in the worst case scenario entire application) as soon as possible. However, a broken feature is only the symptom of the broader problem. If we focus only on fighting the symptoms most certainly we will face the same problem sooner or later. Therefore, once the problem on hands is fixed, we should take time to uncover what was the real reason for which this problem occurred.

Continue reading Root Cause Analysis

Business Model Canvas

To make a smart decision about the business, you are going to create or one you represents you have to know everything about it. You have to be aware who will be your costumes and partners. You need to know what you will be providing to them and how you will give it. And the most important, you need to know what will generate your costs and from where your income will come. The Business Model Canvas is a tool (template) which will help to visualise your business model.

Continue reading Business Model Canvas

Product Backlog

The Product Backlog (PB) is an ordered list which contains all things needed to be done in order to make product successful. The Product Backlog is the one and only source of the requirements for the product created by the Scrum Team. And there is only one person accountable for the Product Backlog. It’s Product Owner.

Continue reading Product Backlog

Definition of Ready

To make cooperation between the Development Team and the Product Owner a Definition of Dane has been introduced (you can read about it here). DoD makes easier to manage the expectation for the Development Team. But this is a two-way street. The Product Owner expect something from the Development Team and the Development Team expects something from the Product Owner. They expect from him or her to provide a sufficient information about what they need to do. To make it transparent, and Scrum is all about the transparency, Definition of Ready has been introduced (commonly known as DoR).

Continue reading Definition of Ready

Definition of Done

In the Scrum Guide a very straightforward definition of a Sprint can be found:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

It is quite obvious what “useable” and “potentially releasable” means. But what exactly means “Done” increment.  If we ask 10 people when a website (simple example) is done, we probably will have 10 different answers. But scrum relies on transparency and to avoid the ambiguity the Definition of Done has been introduced.

Continue reading Definition of Done