Agile Transformation at an International Media Conglomerate: Based on a True Story | Part Six




AT - cx CIRCLE - 9B SG lowerres




Agile Transformation at an International Media Conglomerate: Based on a True Story

Scott M. Graffius, CEO of Exceptional PPM and PMO Solutions™, helps companies achieve their strategic objectives and business initiatives through project management leadership. A fantastic agile transformation outcome with a client organization in the entertainment industry was the inspiration for Scott's award-winning book,
Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions. This is the story behind the book—told by Scott. Identifying details have been changed and certain elements are not included.

This article is the sixth installment of the eight-part story. If you haven't already read the earlier parts, you can find them here:


Part Six: The Pilot – Sprint Planning and Sprint Execution

at---cx---the-call---sg---9b9---p6-lowerres-squashed

The Product Owner, Scrum Master and I discussed sprint planning techniques. The Scrum Master decided that the meeting event would be handled via two separate sessions—part 1 (what will be committed to for the upcoming sprint) and part 2 (how to accomplish the work identified in part 1).

For sprint planning part 1, the timebox (not to exceed duration) for the meeting was calculated as:

  • 2
  • multiplied by the number of weeks in the upcoming sprint (2 in this case),
  • which equaled 4 hours for the event.

The Scrum Master made the following information visible during the event: start and end dates for the sprint, (after a sprint was completed) the results of the last sprint review event, and (after a sprint was completed) the results from the last sprint retrospective event. The Product Owner reminded the Development Team about the product vision statement, and the Product Owner shared the sprint goal (such as "implement shopping cart functionality ..."). The Development Team determined their capacity in work hours for the upcoming sprint. It was calculated as:

  • the number of people in the Development Team
  • multiplied by the number of project productive hours (which excluded time outside the sprint such as company meetings, trainings, vacation time, etc.) per workday
  • multiplied by number of workdays in the sprint.

(Estimation via story points, and prioritization by the Product Owner were already taken care of.)

For each item in the product backlog, participants discussed the user stories/requirements including acceptance criteria, assumptions, dependencies, risks, and anything else requiring a conversation to get a good understanding of the item. The Development Team then committed to the entries which they thought could be completed in the upcoming sprint. The technique they employed involved asking "Can we do this first item in the product backlog?" If the answer was yes, they selected it and proceeded to the next item and continued until the team believed that no more work could be done in the sprint. After the Development Team had worked together and had data on actual velocity (the number of story points completed in a sprint), they also considered that historical metric—comparing it with story points for items in the sprint. The Product Owner updated the product backlog, identifying the items committed by the Development Team to be done for the upcoming sprint.

For sprint planning part 2, the timebox for the meeting was calculated as:

  • 2
  • multiplied by the number of weeks in the upcoming sprint (2 in this case),
  • which equaled 4 hours for the event.

The Scrum team created the sprint backlog. It had the following columns:

  • ID#,
  • Description,
  • Story points,
  • Task information (meetings, designs, coding, code review, testing, etc.),
  • Estimation in hours (they adopted the practice that if effort is greater than eight hours, split the task into smaller ones),
  • Owner (where members of the Development Team self-assign tasks),
  • Status, and
  • Hours of work remaining.

During the meeting, the Scrum team compared the total estimated work hours for the sprint with the Development Team’s capacity (mentioned under the part 1 meeting) for the sprint. If the Development Team believed that the sprint backlog contained too much work to be done during the sprint, they collaborated with the Product Owner to remove one or more items. If the Development Team believed they could handle more work during the sprint, they worked with the Product Owner to move one or more of the high priority items from the product backlog to the sprint backlog.

The Product Owner, Scrum Master and I discussed sprint execution. Select examples of what was decided and done are highlighted next.

The Development Team set up a task board (also known as a Scrum board) to reflect the work in the current iteration. They went with a simple format. The board depicted work in rows and columns where rows included work items, and columns reflected status (To Do, Doing, and Done). Work was addressed from top (highest priority) to bottom, and work migrated from left to right on the task board as it progressed. The task board is also covered in the daily Scrum meeting.

The Scrum Master decided to use a sprint burndown chart to track and communicate progress during the sprint. He set it up and updated it each workday, usually immediately after the daily Scrum meeting.

The Scrum Master created an impediment backlog to capture things preventing the team from progressing or improving. This backlog was updated daily, typically immediately after the daily Scrum meeting.

At the daily Scrum meeting event, the Development Team shared status, plans, and any impediments. Before this pilot with changes, the team was not conducting the daily Scrum (or updating the task board, burndown chart, and impediments backlog) consistently. Under the pilot (and subsequently), the Development Team met for up to 15 minutes (timebox) each workday, and it was conducted at the same time (10:00 a.m.) each day. At this daily stand-up session, the Development Team and the Scrum Master met where the task board, sprint burndown chart, and impediment backlog were posted. Each Development Team member described what he/she worked on since the last Scrum meeting, and he/she updated the task board. Next, the same Development Team member explained what he/she would work on that day, and he/she updated the task board. Lastly, the same Development Team member reported any impediments. (The Scrum Master recorded any issues in the impediments backlog. If a discussion was required, it took place immediately after the daily Scrum. The Scrum Master helped resolve impediments.) The steps were repeated for other members of the Development Team.

The Scrum Team built an increment of functionality during every sprint, and the increment was potentially shippable because the Product Owner might decide for it to be implemented at the end of the sprint. Said differently, potentially shippable is defined by a state of confidence or readiness, and shipping is a business decision. Commencing with the pilot, the organization started releasing products as often as every sprint (two weeks).

Agile Transformation at an International Media Conglomerate: Based on a True Story continues with Part Seven: The Pilot — Sprint Review and Sprint Retrospective.

black_spacer_lr_sq_v3



© Copyright 2019 Scott M. Graffius. All rights reserved. This material may not be published, broadcast, rewritten or redistributed without the express written permission of Scott M. Graffius.







custom - back to main page of blog