Sprint Retrospective Meeting

1. Meeting for scrum team to retrospective on how the Sprint went with respect people, process and tools.
2. Team identifies what went well and what can be improved.
3. Team identifies a plan to implement identified improvements.
4. Other stakeholders are not allowed.
5. An opportunity for the team to make continuous improvements.
6. Maximum time box of 3 hours for a 4 week Sprint

The Sprint Retrospective Meeting - Warnings

1. The retrospective meeting is not conducted.
2. Identified improvements are not followed up with actions.
3. The scrum master or/and development team does not attend.
4. Other stakeholders are not allowed.
5. Maximum time box of 3 hours for a 4 week Sprint.

What is Sprint Retrospective?
Each Sprint in Scrum has to a meeting – Sprint Retrospective at the end. It is very essential that the Scrum Master never allows the team to skip these meetings. These meetings uplift Inspect and Adapt principles of Scrum and help the product to be better and better after each Sprint.

Team along with Scrum Master asks 2 questions:

• What went well in last sprint?
• What could be improved in next sprints?

  Rules for Sprint Retrospective ?

1. Ensure that everyone can speak freely.
2. Sprint retrospective meeting is not the place for advocating ones personal agenda.
3. Do not play the blame game.
4. Do not allow vague statements.
5. Transform identified improvements to concrete action points.

Key elements of the Sprint Retrospective are:

• Process improvements are made at end of every Sprint - ensures that the project team is always improving the way it works.
• The Retrospective is a collaborative process between all members of the Team, the Product Owner, and the Scrum Master.
• All team members identify what went well and what can be improved
• Scrum Master prioritises actions and lessons learnt based on Team direction
• Team devises solution to most vexing problems - helps to build the team ownership and self management.
• Helps the team formation and bonding as any areas of conflict can be identified and dealt with.

The Sprint Planning Meeting

Who, What, When, Where, Why
The Sprint Planning Meeting is attended by the product owner, Scrum Master, and the entire Scrum Team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies.

Two defined artifacts that result from a sprint planning meeting:

A sprint goal

A sprint backlog

A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner. The following are typical sprint goals on an eCommerce application:

There are two parts in Sprint Planning Meeting

Part 1 – Prioritization 

What needs to be done by the end of this upcoming Sprint?

1. PO presents the ordered backlog items to the team.
2. Team discusses and understands the work for this Sprint.
3. Team forecasts and commits on the items that can be done.
4. Team creates the Sprint Goal for this Sprint.

Part 2 – Planning How will the chosen work get to done?

The output of the second planning meeting will be the Sprint Backlog.

1. Team arrives at the plan to get the items to done in a Sprint Backlog.
2. Team arrives at a design and work needed to achieve the Sprint goal.

The Sprint – 6 Early Warning Signs

1. The goal of the Sprint explicitly changes during the Sprint.
2. Certain changes are done that cause goal to change during the Sprint.
3. Team composition is changed during the Sprint.
4. Definition of done is changed during the Sprint.
5. Sprint duration extends beyond the agreed time-box.
6. Sprint duration is agreed to be beyond a month.

Meetings keep getting longer and there are too many of them.

If  daily standups are getting longer and longer, watch out. Something is going wrong. The team may be losing focus or getting off track. If more and more meetings are being scheduled to resolve issues, the team is likely to be struggling.

These are early warning signs of trouble. Pay attention. Keep to the 15-minute time limit for standups and use informal discussions rather than formal meetings whenever possible.

2. The team follows a hierarchy and seeks approval before acting.

At times teams will establish one or more hierarchies. For example, there may be an acknowledged system architect, a keeper of the build, or a quality guardian. It’s fine to have designated subject matter experts (SME). Problems develop when the team stops and waits for SME approval. The SME quickly becomes a bottleneck, slowing the team down.

If there is a SME on the team, that person should guide the team not look over everyone’s shoulders. A SME that is protective of his territory will only hurt the team.

3. The team keeps getting bigger.

Sometimes agile teams will add people to try and do more in less time. The strategy can work if there is enough time left in the plan for the newcomer to have a meaningful impact.

Management may conclude that if adding one more person helped, why not add another? And another? Maybe the underlying problems that are causing the team to appear understaffed should be fixed. If the team gets too large, consider splitting it into two autonomous teams.

4. Deadlines are missed and sprints are lengthened.

One solution to the problem of missing sprint deadlines is to make the sprints longer, right? It sounds reasonable but if the team is having trouble planning and executing short sprints, it will only get tougher to manage longer ones.

Missed deadlines are a symptom. There are many possible causes of the underlying problem. The key point is that if deadlines are missed, you need to dig deep and understand why.

5. The team gets bogged down in documentation and becomes resistance to change

At times, some people new to agile development may be uncomfortable with a lightweight agile approach. They may attempt to make up for that by ‘writing things down’ and trying to control change. This may also result in each sprint decomposing into analysis, design, code and test segments.

Retrospectives can help.

Scrum Sprint

Events in the Scrum Framework
Sprint = [ Sprint planning meeting + Daily Scrum +Development work + Sprint review + Sprint retrospective ]
Time-box of less than a month when team gets to “Done” a potentially shippable product increment.•Each Sprint contains:

1. A goal.
2. A design and plan to reach the goal.
3. The work done to achieve the goal.
4. The product increment.

The Sprint Cycle

Each sprint begins with a planning meeting. During the meeting, the product owner (the person requesting the work) and the development team agree upon exactly what work will be accomplished during the sprint. The development team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria needs to be met for the work to be approved and accepted.

The duration of a sprint is determined by the scrum master, the team's facilitator. Once the team reaches a consensus for how many days a sprint should last, all future sprints should be the same. Traditionally, a sprint lasts 30 days.

After a sprint begins, the product owner must step back and let the team do their work. During the sprint, the team holds daily stand up meeting to discuss progress and brainstorm solutions to challenges. The project owner may attend these meetings as an observer but is not allowed to participate unless it is to answer questions. (See pigs and chickens). The project owner may not make requests for changes during a sprint and only the scrum master has the power to interrupt or stop the sprint.

At the end of the sprint, the team presents its completed work to the project owner and the project owner uses the criteria established at the sprint planning meeting to either accept or reject the work.