The two most popular charts allowing to follow a team’s progress during the Sprint are Burndown Chart and Burnup Chart. Both are not perfect tools but good enough to see how the team is progressing through the Sprint (release, etc). However, before any team decides which one to use all team members (and organization) must understand what information is presented and how to read them – as some times this can be misleading.Continue reading Burnup Chart vs. Burndown Chart
When the new team forms or the project/team changes it is always good to know who can do what and who need help with what. It is important to find out
The hart of each Sprint is the Daily Scrum, also known as Stand-up. This 15-minute time-boxed meeting is designed for the Development Team. Its primary goal is to synchronise the team’s effort towards achieving the Sprint Goal.Continue reading Daily Scrum
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 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
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?
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.
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.
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.
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.