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
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
It is a well-known fact that having a goal defined helps to accomplish it. A written down goal, if located in a visible place, is a consistent reminder and motivator. It is a public demonstration of internal desires.
Continue reading Sprint & Release Goals
The way to a team’s perfection is an everlasting journey. It starts when the team is set up and ends when it is dissolved. How long it takes depends on the purpose for which the team has been created. For some teams it might be 3 months and for some a year or longer. Continue reading Sprint Retrospective