A Project Manager’s Approach to Scrum for the Development Team

Introduction

*Sprint = Iteration

*Backlog = Stack

*Daily Scrum Meeting = Daily Workshops

In terms of the Software Development Life Cycle (SDLC); Scrum is comprised of 5 phases.

• Concept Phase – Iteration -1 (usually 1 week)Business Case
• Inception/Iteration Phase – Iteration 0 (usually 1 week)Project Charter
• Product Backlog
• Construction Phase (usually 2 weeks per Sprint)Sprint Information Page
• Sprint Release Plan
• Construction Sprints
• Daily Scrum Meetings
• Quality Assurance

1. Coding conventions
2. Guidelines

• Testing
• Sprint Review/Demos
• Sprint Retrospectives
• Release/Transition Phase (usually 5 weeks)Final testing
• Rework
• Finalize system and documentation
• Training
• Deploy the system
• Production PhaseOperate and support system in production

Scrum Theory

An empirical process control theory – knowledge comes from experience and making decision on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. The Scrum team will usually consist of a Product Owner, Project Manager/Scrum Master and Development Team (Project Manager is considered part of this team).

Scrum Events

These time-boxed events are to create regularity and minimize the need for meetings. Each event in Scrum is a formal opportunity to inspect and adapt something.

User Stories

A User Story is a very high-level definition of a requirement, containing just enough information so that the Development Team can produce a reasonable estimate of effort to implement it

Definition of “Done”

When a Product Backlog item or an increment is described as “Done”, EVERYONE on the team must understand what “Done” means. Team members must have a shared understanding of what it means for work to be complete, to ensure transparency. This guides the understanding of how many Product Backlog items can be selected during Sprint Planning.

Result:

In the beginning the Story Definition of Done is “A story is done when the Tester says so and it is ready for the QA and acceptance testing”

Definition of “Ready”

Product Backlog items that can be “Done” by the Development team within one Sprint are named “Ready” for the selection by the Development Team and Product Owner in Sprint Planning.

1.??Project Charter

A Project Charter is a document which outlines the purpose of the project, the way the project will be structured and how it will be successfully implemented. The Project Charter is a critical artifact that is developed during the initiation phase by the Sponsor or Project Manager. It usually consists of the following:

?Project Purpose

• Vision, high-level objectives, scope and deliverables (i.e. what we have to achieve)
• High-level stakeholder list (i.e. who will take part in it)
• Project Approach (i.e. how it will be undertaken).

?

Why is the Project Charter So Critical?

The Project Charter ensures project stakeholders share a common understanding among the team of why the project is being done, the timeframe, deliverables, boundaries, approach and responsibilities.

Simply put, the dedicated team should have a clear understanding of the project description that answers the classical questions “What”, “Where”, “When, “How”.

The Project Charter may also be referred to as a “Terms of Reference (TOR)” or “Project Definition Report (PDR)” or “Product Overview Document”. Please see Appendix A: Project Charter

?2.??Product Backlog

An importance ordered list of requirements that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Backlog is dynamic; it constantly changes to identify what the product needs. The Product Backlog is the result of refining the Product Owner’s vision into concrete deliverables. Therefore, the Product Owner should be the one to have the final say of prioritization.

The Product Backlog must be prioritized by importance and in good shape before the Sprint planning meeting occurs from High -> Low Importance. In addition to the usual Product Backlog, the Product Owner defines a list of acceptance thresholds, which is a simple classification of what the importance level in the Product Backlog.?

Product Backlog Item

The Product Backlog Item (PBI) may also be referred to as a “User Story”. PBI’s have an ID and are prioritized; the higher the order the more detailed and important than the lower ordered ones. E.g.) 10. Or 150. High = more important). The Product Back will include the initial estimate of velocity and later in the Sprint Backlogs a more relative estimate will be made. Product Backlog Items/User Stories usually comes in the form of Index Cards that will display the following attributes followed by a discussion by the team:

Front of Card:

• PBI ID
• Description (following this format)
• As [role],
• I want [something]
• So that [benefit]
• Priority – level of importance (high – >low)
• Effort Velocity (Size, Complexity)
• Poker Planning

Back of Card:

• Acceptance Criteria (following this format)
• Given [context]
• When [event]
• Then [outcome]

Bug Tracking can also be considered a PBI.

*If an Agile Scrum tool such as VSTS is used, this information can be entered in the PBI. *

Epics

Epics are very large PBI/User Stories, typically ones which are too big to implement in a single Sprint/Iteration and therefore they need to be broken down into smaller PBI’s at some point. Epics are lower priority PBI’s because once the Epic works its way towards the top of the Product Backlog stack it probably has already broken down into regular PBI’s. Epic’s do NOT consider bug tracking. Epics, usually are filled in by the PM or Product Owner.

Features

Features are a smaller Epic but large enough to be broken down into a PBI. Bug Tracking can also be considered a Feature. Features, usually are filled in by the PM or Product Owner.

Tasks

Tasks are broken down PBI’s small enough to estimate by hours - six hours a day. The assigned team member will provide Sprint Backlog Item (SBI) information along with priority, effort and remaining hours.

3.??Sprint Planning

Sprint Goal

A short statement of what work will be focused on during the Sprint.

Team Members

There should list team members and their level of commitment. Stakeholder Assessment Matrix

Sprint Planning Meeting

The purpose of the Sprint Planning Meeting is to give the team enough information to be able to work in undisturbed peace for a few weeks, and to give the Product Owner enough confidence to let them do so. This meeting will happen before each sprint and should include the Product Owner that will talk about 2 sprint’s worth of PBI’s.?

In the Sprint Meeting all PBI’s should be sorted by importance that the Product Owner believes has a possibility of being included in the next Sprint which should be given high importance. The Product Owner has the right to assign importance levels of the selected PBI’s for each Sprint.

The velocity should be re-estimated by the team for at least the next 2 sprints.

• Effort Velocity (Size, Complexity)
• Planning Poker
• Remaining Hours
• the team member assigned to the SBI assessment of how much work is needed to implement roughly in “ideal man-hours”.

Sprint Release Plan

Now that the velocity has been determined the Product Backlog can easily be decomposed into the number of Sprints for the project. After the Sprint Release Plan usually a Sprint Burndown Chart is created which is the same as the Sprint Burndown Chart but with the Sprints illustrated as bars. The Project Manager usually creates the Sprint Release Plan and Sprint Burndown Chart.

Sprint Backlog

This is the selected PBI’s for the Sprint and the work needed to deliver that functionality into a “Done”, where the Product Owner has the final say.?Post-it’s should be used for each 4 columns. The Sprint Burndown Chart should include the Effort Hours and Sprint Dates of the current sprint.?

The Sprint Backlog is used in the Daily Scrums for each Sprint. This should include the following 4 columns:

• Sprint Goal Description of the Goal
• Manually draw and plot a new point on the burndown every day after the Daily Scrum
• StoryIncludes the deliverable name
• As a … I want… (5)
• Not StartedTasks that nobody is working on today
• Deliverable Tasks
• In ProgressTasks that being worked on today
• Done!Tasks that nobody will work on any more

Sprint Info. Page

Right after the Sprint Planning is complete, the PM will create a Sprint Info Page?and post it a?Wiki, and send an email to the team, which includes the sprint demo date, time and place for the daily scrum. A follow up email is sent when the Sprint nears the end and ready to demo.

Sprint

The heart of Scrum is a Sprint, a time-box of one month or less (usually 1 – 2 weeks) during which a “Done”, product increment is created. During the Sprint scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. Each Sprint has a definition of what is to be built. Sprints artifacts consists of:

1. Daily Scrums – 15-30 min time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. Half of this workshop is to inform what work has been done since the Daily Scrum and the other half is to forecast the work that could be done. The Product Owner’s presence is optional.

• What did I do yesterday?
• What will I do today?
• Do I see any constraints that prevents me from doing my forecasted work?

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal.?This helps manage Sprint progress.

1. Development Work – work done by the Development Team

?

1. Sprint Review & Demo – held at the end of the Sprint to inspect the increment and adapt the Product Backlog if needed. This is an informal meeting, not a status meeting, and the presentation of the increment is intended to elicit feedback and foster collaboration.

• Review the Sprint Goal to determine the success.
• The Product Owner is aware of what has been “Done” and what has not been.
• Development Team demonstrates all that was done
• Discussions on what problems occurred and how they were solved
• Revised Product Backlog that defines the Product Backlog for the next Sprint. May add additional features too.
• Preliminary discussion of what happens next to help prepare for the next Sprint Planning.
• Timeline, budget, marketplace anticipated release of the product
• Burn charts or cumulative flows may be discussed.
• Focus on “What did we do” rather than “How did we do it”.

?

1. Sprint Retrospective – This should occur right after the Sprint Demo and the next Sprint Planning should occur the next day so people have enough time to absorb information and not feel overwhelmed (Friday would be perfect for this). This is an opportunity for the team to inspect itself and create a plan for improvements for the next Sprint. This meeting should be between 1 – 3 hours and should be in a place that is very neutral like a lunch room. The focus should be on “What can we do better next sprint”.?

• Inspect how the last Sprint went with regards to people, relationships, process, and tools.
• Identify the order the major items that went well and potential improvements and create a plan.
• Teams plans ways to increase product quality – “Done”

?Appendix A: Project Charter

Project Name:

Project Purpose:

Project Definition: High-Level

• Vision Statement
• Objectives
• Scope
• Deliverables

Project Organization

• Customers
• Stakeholders
• Roles
• Responsibilities
• Project Org Chart

Success Criteria

Project Considerations

• Risks
• Issues
• Assumptions
• Constraints

Milestone Schedule

Project Approach: Agile Scrum

?#SCRUM