Sprint Mails

A few weeks ago at the 2013 ALM Summit I gave a presentation titled Un-Managing Agile Teams covering my perspective on how to create healthy environments for agile development teams. The full talk is available at the link above.

During the talk I shared some a few of the practices we use with our own teams – one of those practices is what we call “sprint mails”. So, what is a sprint mail?

Let me start by sharing a bit about our process. Our teams work in 3 week sprints. Now, these aren’t just 3 week “time periods”… but real sprints that you’d expect from a scrum team. We start and finish stories during a sprint, and follow the basic mechanics – sprint planning, daily scrum/stand-up, retrospectives, etc. Our teams range from 8-12 people, made up of dev, QA, and a product owner. One of the practices that we’ve developed to keep everyone in the org up to speed is to have each team send two mails during the sprint – these are what we call sprint mails.

The first mail is sent after the team completes sprint planning (usually at the end of day 1 of the sprint). The goal of the mail is to share broadly what the team has planned for the sprint. The mail usually consists of a list of stories the team is tackling, along with a basic description of the goal for the sprint. Nothing too fancy, just some basic sharing of the plan the team has put together.

At the end of the sprint, the team sends another mail communicating what they accomplished during the sprint. The same list of stories are included with updates on progress; and if the team has completed a story or set of stories, they include a short video demo’ing the functionality. The demo videos are key because they show the changes there were made in a way that pictures or text can’t convey.  In the attached screenshots you can see the level of detail we include in these mails.  The stories from this particular sprint (sprint 39) shipped on the Team Foundation Service late last year.

Sprint mails have become a standard practice for our teams to help communicate plans, progress, and celebrate success.  They keep everyone abreast of what’s going on with partner teams, and they provide a place for the team to publically celebrate key achievements.

Comments

• Anonymous
  November 18, 2013
  We could come across situations where the product owner has to decide to add/remove any item from the Product Backlog or change the priority of the items listed in the Product Backlog in the middle of a Sprint. This could be a challenge for the Scrum Master and the Development Team as it would hamper the Sprint in progress, especially changing the priority of the backlog items. Even though Scrum has enough room for responding to change, the mid-sprint alterations should be kept minimal and should not be tolerated unless very badly required. The sprint backlog user stories must not be altered in the middle of a sprint except in the rare scenario something far-reaching emerges that can’t wait until the next sprint.http://scrumstudy.com/