Tag Archives: Scrum

Agile, Ceremonies, Templates

Iteration Review

Leave a comment

Although this material may be found in a variety of places on the web, clients have often asked me to provide them write-ups and explanations.  Enclosed is a brief summary of the Iteration Review.

Pre-Requisites

Product Owner, Team and ScrumMaster shouldn’t spend more than 1 hour prepping for an Iteration Review.  Ideally is should take about 30 minutes for them to agree on what they are presenting and demonstrating.

Duration

½ hour to 2 hours

Purpose

The Purpose of the Iteration Review is for the Product Owner, Team, and ScrumMaster to present the Iteration’s product increment to their stakeholders.  Often this is driven by the Product Owner and he/she drives communication with his/her constituents.  The Team supports the Product Owner by providing a demonstration or presentation of the work that was done.  Typically the Product Owner provides the color commentary as the Team presents the product increment.

It’s very important for the Product Owner, Team and ScrumMaster to have ample time for interaction with their Stakeholders and encourage them to provide feedback.

The ScrumMaster typically helps collect the data for the “Quadrant Page”.

The Quadrant Page consists of four areas:

  1. Iteration Goal,
  2. Named User Stories for the Committed for the Iteration,
  3. Targeted User Stories for the Upcoming Iteration,
  4. Iteration Metrics.

The Iteration Metrics that are typically of interest are:

  • # of Stories Committed,
  • # of Points Committed,
  • # of Stories Delivered,
  • # of Stories Not Delivered,
  • Iteration Velocity,
  • Average Velocity,
  • # of Test Cases Run,
  • # of Defects,
  • # of Defects Fixed,
  • # of Defects Rejected.

Attendees

Participants1

  • Product Owner
  • Team
  • ScrumMaster
  • Stakeholders

Observers2

  • Anyone

Concludes

When the team has finished presenting the product increment and the stakeholders have had their questions answered and/or feedback captured.

Standard Scrum Ceremonies / Meetings

  1. Participants in this document refer to individuals critical to the meeting and are allowed to talk during the meeting. ↩
  2. Observers in this document refer to individuals allowed to observe meetings, but aren’t allowed to talk during the meeting. ↩

Agile, Ceremonies, Estimating, Planning

Product Backlog Grooming

1 Comment

Although this material may be found in a variety of places on the web, clients have often asked me to provide them write-ups and explanations.  Enclosed is a brief summary of the Product Backlog Grooming.

Pre-Requisites

The Product Owner has a prioritized Product Backlog that aligns with their Release Plan and Roadmap.  To help expedite the meeting, the Product Owner should send out a list of stories that he/she wants the team to estimate. The team can then do any necessary research.

Duration

1 hour, 2 to 4 times during an Iteration

Purpose

The purpose of Product Backlog Grooming is for the Product Owner to present new stories to the Team, discuss the stories intent, capture the acceptance criteria and story point the story.  It is a time-boxed meeting where the goal is to estimate as many stories as possible in the allotted time.

If this meeting is conducted regularly, Iteration Planning – Part 1 will be much faster and smoother for everyone.

Attendees

Participants1

  • Product Owner
  • Team
  • ScrumMaster

Observers2

  • Anyone

Concludes

This concludes when the meetings allotted time has expired or all the stories that were prioritized for that session have been estimated (planning poker).

Standard Scrum Ceremonies / Meetings

  1. Participants in this document refer to individuals critical to the meeting and are allowed to talk during the meeting. ↩
  2. Observers in this document refer to individuals allowed to observe meetings, but aren’t allowed to talk during the meeting. ↩

Agile, Ceremonies, Templates

Iteration Retrospective

Leave a comment

Although this material may be found in a variety of places on the web, clients have often asked me to provide them write-ups and explanations.  Enclosed is a brief summary of the Iteration Retrospective.

Pre-Requisites

None (for the “basic” Retrospective)

Duration

1 to 1 ½ hours

Purpose

The purpose of Iteration Retrospective is for the Team, Product Owner and ScrumMaster to reflect on the Iteration and inspect and adapt.  There are a variety of ways to run a Iteration Retrospective, but the “basic” Retrospective poses three questions to the participants:

  1. “What worked well?”
  2. “What did not work well?”
  3. “What should we change, add, or remove?”

Unless otherwise agreed to by the participants, the findings and discussions of an Iteration Retrospective are considered private to the team.  The reason is this is considered a “safe” meeting for the team.  They should feel free to discuss whatever they like without repercussion or concerns.

Often the Iteration Retrospective is under-valued by those new to Agile, but this is a very important activity.  This is the only meeting dedicated to improving the team.

Attendees

Participants1

  • Team
  • ScrumMaster
  • Product Owner (optional, but we feel it’s very beneficial to teaming if they attend)

Observers2

  • None

Concludes

The Iteration Retrospective concludes when the team feels they’ve completed answering the 3 questions and when improvement actions are documented and assigned for the upcoming iteration.

Standard Scrum Ceremonies / Meetings

  1. Participants in this document refer to individuals critical to the meeting and are allowed to talk during the meeting. ↩
  2. Observers in this document refer to individuals allowed to observe meetings, but aren’t allowed to talk during the meeting. ↩

Agile, Ceremonies, Stand-Ups, Templates

Daily Stand-Up / Scrum Meeting

Leave a comment

Although this material may be found in a variety of places on the web, clients have often asked me to provide them write-ups and explanations.  Enclosed is a brief summary of the Daily Stand-Up / Scrum Meeting.

Pre-Requisites

Participants have updated their tasks to reflect new estimates for their work.

Duration

15 Minutes (maximum) + time for the “16th Minute”

Purpose

The purpose of this meeting is for the team to re-synchronize and re-evaluate their progress with each other on a daily basis.  Note: it’s not a status meeting for the ScrumMaster; it is a daily planning meeting for the team, as they are planning their work for the day.

The stand-up is for the team to make sure they still feel they are on-track, synchronize their work with their teammates, re-evaluate work remaining, and identify / raise impediments.

Each participant answers 3 questions:

  1. “What did I get done yesterday?”
  2. “What do I plan on accomplishing today?”
  3. “Do I have any impediments?”

Often because of time zone challenges I suggest changing the questions to:

  1. “What did I get done since the last stand-up?”
  2. “What do I plan on getting done before the next stand-up?”
  3. “Do I have any impediments that I wish to escalate that I require assistance with?”

Attendees

Participants1

  • Team
  • ScrumMaster
  • Product Owner (optional, but we feel it’s very helpful if they regularly attend)

Observers2

  • Anyone

Concludes

When each participant in attendance has provided their update to the team and the team has reviewed the burn-down chart.

The “16th Minute”

After the Stand-Up concludes, we encourage the participants to stay around and work things out as needed.  It’s also an opportunity for Observers to then ask questions of the team.  Team members that are impacted are identified prior to the beginning of the 16th minute.  Others are free to leave.

For scheduling purposes plan on another 15 minutes, but it is typically less than that.

Standard Scrum Ceremonies / Meetings

  1. Participants in this document refer to individuals critical to the meeting and are allowed to talk during the meeting. ↩
  2. Observers in this document refer to individuals allowed to observe meetings, but aren’t allowed to talk during the meeting. ↩

Agile, Ceremonies, Stand-Ups

Story-Based Stand-Ups

Leave a comment

Many agile teams have become accustomed to conducting stand-ups, but there are times when the basic stand-up may not be as effective and efficient as communicating progress and aiding team with work re-synchronization.

The basic Stand-Up typically follows this protocol:

  • The team recognizes the Stand-Up is about to start;
  • In a clock-wise fashion each team member, as well as the scrum master, answers the following questions:
  1. “What did I get done yesterday?”
  2. “What do I plan on accomplishing today?”
  3. “Do I have any impediments?”

This type of stand-up works fine, but for team members that are remote this can be challenging for a variety of reasons:

  • Team members often don’t speak up during the tele-conference call.
  • Team members tend to fail to indicate which stories they are working on.
  • The continuity of a story and its completion is broken up as we go around the team room during the Stand-Up.

If you are experiencing this problem, or want to experiment with something different, I have had some teams change to a story focus during their Stand-Ups.  Instead of having the organizing principle be the individual, the organizing principle shifts to the story.  As Larman and Vodde state in Scaling Lean & Agile Development, “this allows us to focus on the baton and not the runner”.

A Story-Based Stand-Up would proceed as follows:

  • The team recognizes the Stand-Up is about to start;
  • Based on story priority, with the most important story going first, each team member working on that story or planning to work on that story, answers the following questions:
  1. “For this story, what did I get done yesterday?”
  2. “For this story, what do I plan on getting done today?”
  3. “For this story, do I have impediments?”

Since it is story based, if a team member is working on more than one story he will address his progress when it comes time to discuss the other story.

Pro(s) of this approach: Shifts from individual to story.  Keeps the team focused on trying to finish a story.  Helps to not confuse effort with results, keeps the focus on delivering business value – the story.

Con(s) of this approach: Team members will speak multiple times, but only when their work lines up with story.  All work needs to be accounted for in stories (some would argue that’s a good thing.

Give it a try.  See if works for you.

Remember, don’t just “Do Agile,” “Be Agile!”