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 with what the team can deal on their own. However, I think that most important is to know with what they need help.
Continue reading Retrospective: things I can and can’t do…
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?
Continue reading Sprint Retrospective for Scaled Scrum
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
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
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
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
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