The Story Behind “Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions” - Agile Transformation at an Entertainment Company | Part 6
05 April 2019
Agile Workflows
The Story Behind Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions — Agile Transformation at an Entertainment Company
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 1: The Call;
- Part 2: The Goals;
- Part 3: The Environment;
- Part 4: The Options; and
- Part 5: The Pilot – Vision, Roadmap and Release Plan, and Product Backlog.
Part 6: The Pilot – Sprint Planning and Sprint Execution
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).
The Story Behind Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions — Agile Transformation at an Entertainment Company continues with Part 7: The Pilot — Sprint Review and Sprint Retrospective.
About Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions
Shifting customer needs are common in today's marketplace. Businesses must be adaptive and responsive to change while delivering an exceptional customer experience to be competitive.
There are a variety of frameworks supporting the development of products and services, and most approaches fall into one of two broad categories: traditional or agile. Traditional practices such as waterfall engage sequential development, while agile involves iterative and incremental deliverables. Organizations are increasingly embracing agile to manage projects, and best meet their business needs of rapid response to change, fast delivery speed, and more.
With clear and easy to follow step-by-step instructions, Scott M. Graffius's award-winning Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions helps the reader:
- Implement and use the most popular agile framework―Scrum;
- Deliver products in short cycles with rapid adaptation to change, fast time-to-market, and continuous improvement; and
- Support innovation and drive competitive advantage.
Hailed by Literary Titan as “the book highlights the versatility of Scrum beautifully.”
Winner of 17 first place awards.
Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions is available in paperback and ebook/Kindle worldwide. Some links by country follow.
- 🇦🇺 Australia
- 🇦🇹 Austria
- 🇧🇪 Belgium
- 🇧🇷 Brazil
- 🇨🇦 Canada
- 🇨🇿 Czech Republic
- 🇩🇰 Denmark
- 🇫🇮 Finland
- 🇫🇷 France
- 🇩🇪 Germany
- 🇬🇷 Greece
- 🇭🇺 Hungary
- 🇮🇳 India
- 🇮🇪 Ireland
- 🇮🇱 Israel
- 🇮🇹 Italy
- 🇯🇵 Japan
- 🇱🇺 Luxembourg
- 🇲🇽 Mexico
- 🇳🇱 Netherlands
- 🇳🇿 New Zealand
- 🇳🇴 Norway
- 🇪🇸 Spain
- 🇸🇪 Sweden
- 🇨🇭 Switzerland
- 🇦🇪 UAE
- 🇬🇧 United Kingdom
- 🇺🇸 United States
- 🌏 More countries
Let's Connect
Connect with AgileScrumGuide.com on Facebook, Twitter, LinkedIn, Instagram, and Pinterest.
And connect with agile project management practitioner, consultant, award-winning author, and international speaker Scott M. Graffius on Twitter, Facebook, and LinkedIn.
© Copyright 2019 Scott M. Graffius, AgileScrumGuide.com. All rights reserved. This material may not be published, broadcast, rewritten or redistributed without the express written permission of Scott M. Graffius/AgileScrumGuide.com.
