Sprint
A Sprint is a 1-4 weeks timeboxed iteration of a product.
In a Sprint end date and deliverable to not change.
The purpose of each Sprint is to deliver an Product Increment of releasable functionality.
Details
A Sprint can be cancelled by the Product Owner, if the goal of the Sprint is obsolete now.
Product Backlog Refinement
The Product Backlog is the collection of all product requirements.
The Product Owner is responsible for the Product Backlog, but for the Product Backlog Refinement he involves the Development Team to help him.
Attendees (who)
In the Product Backlog Refinement both, Product Owner and Developers work together in harmony.
When
The Product Backlog Refinement is done before the next Sprint Planning Meeting for a specific set of user stories.
Frequency
Every 1-2 weeks
Duration
1-1.5 hours
Sprint Retrospective Meeting
Inspect & Adapt (what)
In this meeting we review the last Sprint, the Product Owners feedback he gave in the Sprint Review Meeting and we have a look at the last Retrospective Meeting:
- Are there lessons learned?
- Are there opportunities for improvement?
If necessary we create and assign issues with the approach to improve e.g. the process.
Attendees (who)
may be further stakeholders
When
After the Sprint Review Meeting and before the next Sprint Planning Meeting there will ba a Sprint Retrospective Meeting.
Details
It is an opportunity for the team to reflect on how well the Sprint operated for them and they are taken the advice from the Product Owner and the customers.
Sprint Review Meeting
In a Sprint Review Meeting the Development Team shows the finished work to the Product Owner (Demonstration).
Attendees (who)
- Scrum Master
- Product Owner
- Development Team
- Optional: other project stakeholders
When
At the end of each Sprint, the Scrum Master organizes a Sprint Review Meeting.
Details
The Development Team will show the Product Owner a demonstration (Demo) of the work they have done in the Sprint.
It is an opportunity for the Product Owner, the team and customers to talk about the sprint.
All together will decide of “done” has been achieved and the work is completed.
The Product Owner and the Development Team will discuss the Sprint and the items left in the Product Backlog.
Daily SCRUM Meeting
Defintion (what)
The Daily SCRUM Meeting is a 15 minutes timboxed meeting, always at the same location and time.
Participants (who)
SCRUM Master as a facilitator
Agenda (how)
Every member of the Development Team answers these 3 questions:
- What did I do since the last Daily SCRUM?
- What will I do today?
- Are there any impediments in my way of getting things done?
If there are any impediments, the affected issues need to be marked.
Details
It usually takes place at the beginning of each working day. The SCRUM Master works as a facilitator and reminds the team to held the Daily SCRUM.
If there is a real-life task board (e.g. Kanban) and people work at the same location, then they can stand around it.
To ensure that the meeting is kept that short, people stand during the meeting. That’s why it is also called a stand-up meeting.
Based on the outcomes of this meeting the SCRUM Master will update either a Burn-down Chart or a Burn-up Chart.
Sprint Planning Meeting
In the Sprint Planning Meeting the project team discusses the goals of the next Sprint.
The Development Team selects from the top of the Product Backlog the number of User Stories they can accomplish in the next Sprint.
So the question is “How much can we create in this Sprint?”.
The Development Team discusses and decides how the work will be done and how the goal of the Sprint will be achieved.
Product Backlog Grooming
The Product Backlog is owned by the Product Owner.
Grooming is done by:
- adding
- removing
- (re-)prioritizing
- decomposing
- enriching / detailing
requirements, which can be bugs, technical dept, features or stories.
Normally an Issue Tracking System is used, e.g. Jira. So it’s easy to trace this.
Usually the Product Owner does this in close cooperation with the Stakeholders and the Development Team.
Prioritization can be made by considering the following 3 aspects:
- Business Impact
- Risk*
- Necessity/Urgency
* = The risk of a requirement can be determined by analyzing the dependencies to other issues.
A Product Backlog should have at least the top 2 stories “ready-to-implement” stories, normally as much stories that are sufficient for the next Sprint, but never more ready stories than the Development Team is able to implement in 3 Sprints. Further stories, with a lower priority should be only kept vague, so that the knowledge base on which the detailing is made is always as current as possible.
Grooming Workshops
The Product Owner can additionally invite the whole Development Team (and may be also some stakeholders) to a weekly or bi-weekly “Grooming Workshop” or “Grooming Meeting” or “Refinement Meeting”. It can be very useful to choose one big theme / topic. So don’t talk about 20 stories, but some related stories. Optionally the Product Owner can have a 1 hour Pre-Grooming Meeting with one Lead Developer to get at least 1 team member on board upfront and to identify what needs more preperation.
Frequency
Every 1-2 weeks
Duration
A good duration is 1-1.5 hours
Goal
During the Grooming Workshop the Product Owner will find out, if the stories are too big, too small, too detailed, too unclear by using some techniques e.g. Planning Poker. There will be much knowledge transfer within this meeting. Also Acceptance Criteria for stories can be collected together.