Loading

Scrum

Introduction

Scrum is an Agile framework for executing and delivering complex projects. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work.The Scrum framework is simple on paper but hard to implement. This framework has 4 mandatory ceremonies (Sprint Planning, Daily Standup, Sprint Review, and Retrospective), one optional ceremony but highly recommended (Backlog Grooming), 3 roles (Scrum Master, Product Owner, and Dev Team), and 3 artifacts (Burndown Chart, Product Backlog, and Sprint Backlog).

 

When Jeff Sutherland created the scrum process in 1993, he borrowed the term "scrum" from an analogy put forth in a 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review. In that study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the scrum formation used by Rugby teams. Scrum is the leading agile development methodology, used by startup to fortune 500 companies around the world.

 

Sprint Planning (beginning of each Sprint as early as possible on Day 1)

Attendees: Product Owner, Scrum Master, Implementation Team.

At the beginning of each sprint, a sprint planning meeting must be conducted to determine which Product Backlog items will be completed during the sprint and create the corresponding sub-tasks.

Sprint Planning Input:

  1. Top prioritized Stories from Product Backlog are groomed and meets the Definition of Ready.
  2. All Team members are present (in person or over Webex), unless otherwise communicated to the Scrum Master.
  3. Team members should know their own individual capacity for the team prior to Sprint Planning.
  4. Scrum Master displays the JIRA Product Backlog on the WebEx/Projector

The Sprint Planning ceremony should follow the following guidelines:

  1. For a 2 week Sprint, anticipate up to 4 hours for Sprint Planning. Depending on how successful the backlog grooming sessions were will determine how much time you and your team spends in Sprint Planning.
  2. The Scrum Master will perform a capacity analysis by asking the team who will be on PTO, training, etc. and looking at the previous average velocity. The formula is to give each person 8 points per sprint and then subtract 1 point for each day they are not available. A day is further defined as 8 hours. Sprint boundaries are firm. 2 weeks is 2 weeks and capacity analysis is based on the fixed timebox.
  3. Product Owner should be present for the Sprint Planning ceremony with prioritized backlog of Stories. This requires that all User Stories are groomed with Title, Narrative, Description, Acceptance Criteria, and other supporting information as needed.
  4. Product Owner will discuss the sprint goals they would like to accomplish during the sprint and present the prioritized Stories to the team, one at a time, from the top of the backlog. If the story is technical, a spike, or defect, it should be read by someone from the Team. 
  5. Team may ask questions to get clarification on Stories. Details of the story may be updated at this time. Further details of Stories and Sub-Tasks can be discussed during the Sprint, as long as the Team feels confident the Stories will be completed within the Sprint.
  6. If estimation was not done in Backlog Grooming, then the Team estimates the backlog item using the Fibonacci Scale (0, 1, 2, 3, 5, 8, 13, 21, 34, 55…). The Story estimations are based on complexity. Complexity is defined as effort, risks, and unknowns, and is relative to other Backlog items. Therefore, each team should have a baseline story as 1 point, 1 day. This means a Story can be completed by one “ideal” person in 1 day. When the Team does relative sizing, they are comparing the Story size to the baseline Story. For a Story committed to a Sprint, the Story size should be 8 points or less.
  7. If there is support work that the team will do in the Sprint but it is not known at the time of Sprint Planning, the team can put a Support work item as a Technical Story into their Sprint Commitment and estimate it in points. For example, if the team has a velocity of 40 points and they predict roughly 1/5th of their Sprint will be support work, they can give 8 points for the Support Story and add the tasks once the work is defined in detail.
  8. if there is no support work raised in the current sprint then the team can take equivalent Story points from the backlog.
  9. Sprint commitment will be based on the team’s confidence and velocity. The Scrum Master should facilitate the team discussion for committing.
  10. For remote team members, it is important the Scrum Master has access to a screen sharing service, such as, WebEx to share their screen with the team. If possible, tele-presence is highly recommended. For example, if team members are in Europe and the U.S. – having a tele-presence between Europe and the U.S. helps to unite the team and make them feel more like one team. This also is helpful when doing point estimation.
  11. Once the team initially commits to the Sprint Backlog, the team will break down the Sprint Backlog Items into sub-tasks. Each sub-task should be between 2 to 16 hours and have an assignee (the person that will be doing the work). The estimated hours need to be inputted into the estimate field for that sub-task in JIRA.
  • If a Story or Sub-Task is dependent on another Team’s backlog, that Story should be linked to their Story as dependency in JIRA and the Scrum Master should help ensure the dependency does not become a blocker.
  • The Team can use the Sub-Task Breakdown to reconfirm the Sprint Goal(s), verify individual capacity, validate Story estimates, and Sprint commitment.
  • Please Note: Sub Tasks do not directly correlate to Story Points because points represent complexity. Complexity has 3 parts: Effort, Risks, Unknows, Sub Tasks only represent Effort.
  • Please Note: the assumption is that a full time, dedicated person would have 64 hours of capacity in a 2 week Sprint.

Naming Convention for Sub-tasks

A prefix of [Dev], [Services], [Framework], [Test], etc. should be placed in front of the sub-task name.

Sprint Planning output:

  • Sprint Commitment based on Team’s velocity.
  • Sub-task breakdown for all Stories.
  • Sprint Goals identified and agreed to.
  • Sprint started in JIRA.

Daily Standup (as early as possible in the morning from the 2nd day of the Sprint to the last day)

Attendees: Product Owner, Scrum Master, Team.

Each day after the first day of the sprint, the team will meet for fifteen minutes or less to discuss the items they accomplished the day before, what they plan to accomplish the current day and inform the team of any obstacles that may hinder their work. The Daily Stand-up ceremony should follow the below guidelines:

Input:

Prior to the Standup, the team should update the Sub Tasks they worked on with the remaining hours left and the state it is in.

  1. Daily standup should occur as early as possible in the day.
  2. The Scrum Master projects the Scrum Board during the Standup and shares on WebEx for remote team members.
  3. People should stand up during the meeting.
  4. If there are critical updates by outside team members (i.e. removing blockers), they should attend and go first, so they can leave right afterwards.
  5. Based on the prioritized Stories on the Scrum Board, team members should volunteer to give their progress on that Story (based on what they did the day before and what they are going to do today, and if they are blocked).
  6. If issues come up during the Stand-up, the issues should be put into the Parking Lot. After the Standup, the people that need to discuss the parking lot issue(s) should stay back to discuss.
  7. Blockers should be noted and put through an escalation process to help ensure timely resolution.
  8. Team members should close their laptops during the standup, so they can listen to everyone’s progress.
  9. If a team member cannot make the Standup, then the team member should provide an update via e-mail the team before the standup.
  10. After 2 minutes or when you have critical mass, start the Standup even if people are missing.
  11. Before ending the Standup, the Scrum Master should review the Sprint Burndown with the team to ensure everyone is still confident in finishing the Sprint successfully. If certain people are not confident in finishing their work, then have a deeper conversation after the Standup. Sprint Burndown should NOT be used as a micro-management tool.
  12. If PO has concerns about certain Stories, he/she should request a separate meeting or meet after with that individuals or individuals to discuss.

Output:

  1. Clear understanding of what the Team is working on.
  2. Raised impediments that the Scrum Master needs to help get resolved.
  3. Understanding how much progress the Team has made and how much is left.

Note: For remote team members, it is important the Scrum Master utilizes ascreen sharing service, such as WebEx, to share Their screen.

Note: For Logistical purposes, Scrum Teams can stagger their standups to be sequential (back to back) if they are sharing the same Product Owner and/or Scrum Master.
Note: Have a good size room with video/audio conferencing capabilities for the Standups.

Obstacle Removal Process and Escalation

Impediments that are blocking team members from completing their sub-tasks should be put through an obstacle removal process. The obstacle removal process would follow the below process:

  1. The Scrum Master should create and track the blocking issue on a virtual or physical team level Kanban (resolution) board.
  2. After 24 hours (business day), if the blocking issue is not resolved, then the blocking issue should escalate to an immediate technical/business leader.
  3. After another 24 hours (business day), if the blocking issue is not resolved, then the blocking issue should escalate to the appropriate manager.
  4. After another 24 hours (business day), if the blocking issue is not resolved, then the blocking issue should escalate to leadership.

Backlog Grooming (once a week, every week)

Attendees: Product Owner, Scrum Master, Team, and invited SMEs if needed.

Once a week, a Grooming ceremony should be conducted to review backlog items and estimate them accordingly. This ceremony should be timeboxed to 1 hour a week, every week. The Backlog Grooming ceremony should follow the below guidelines:

    Input:

    Prioritized Backlog and groomed stories from the Product Owner perspective.

  1. Product Owner will drive the Backlog Grooming ceremony and should schedule it on the calendar for their Teams.
  2. Product Owner will bring up the backlog of prioritized work items in JIRA to review with the team.
  3. Product Owner reads out each prioritized product backlog item starting from the top prioritized item.
  4. Team discusses, asks questions, and does high level technical analysis for the product backlog item.
  5. If the story is a Technical Story, then the team member who wrote the story will read it to the team. The team will discuss, asks questions, and do any needed high level technical analysis for the product backlog item.
  6. The Team will then proceed to estimate the story. Large stories, typically stories with estimated story points of thirteen or higher, will need to be decomposed into smaller Stories. Product Owner should do this offline. As a rule of thumb, if the Story is too big to be completed by one “ideal” person in the Sprint, then it should be treated as a large Story that needs to be broken into smaller Stories.
  7. Team estimates each backlog item using the Fibonacci Scale (0, 1, 2, 3, 5, 8, 13, 21, 34, 55…). The backlog items are estimated based on relative complexity. Complexity is defined as effort, risks, and unknowns, and is relative to the baseline Story. Therefore, each team should have one baseline Story that can be completed in 1 ideal day, and give that Story an estimate of 1 point. When the Team does relative sizing, they are comparing the Story size to the baseline Story. For a Story committed to a Sprint, the Story size should be 8 points or less.
  8. If dependencies surface (i.e. Spikes, Technical Stories, etc.) in the discussion and therefore, affects the priority of the User Stories in the backlog, then the backlog has to be reprioritized.

Output:

Top prioritized Stories were discussed with the Team and estimated by the Team.

Note: If the stories are not initially groomed by the Product Owner, then use this meeting to pull in only critical members from the team to help initially groom the stories.
Note: For remote team members, it is important the Scrum Master utilizes a screen sharing services, such as WebEx, to share his or her screen.
Note: Ideally, you want to have two Sprints worth of Stories groomed.

Sprint Review (on the last day of the Sprint, towards end of day – but before the Retro)

Attendees: Product Owner, Scrum Master, Team, Invited Stakeholders.

The Review ceremony will be held to formally accept Stories from the Sprint. The Product Owner accepts the Stories, the Scrum Master facilitates, and the Team demos the work completed in the Sprint. This ceremony should be timeboxed between 1 to 2 hours depending on all the stakeholders attending and the scope of the demo. The Sprint Review should follow the below guidelines:

Input:

Sprint Summary Report.

  1. Scrum Master should give a high-level summary of the Sprint’s goals, velocity, and what the Team committed and delivered. For work items not delivered, an explanation should be provided. Scrum Master should only spend 5 to 7 minutes on this.
  2. Product Owner must be present to review the Stories, and confirm that all acceptance criteria have been met. As each Story item is presented by the Team, the Product Owner should accept or not accept the Story based on the Definition of Done, which including the Acceptance Criteria.
  3. Product Owner should only accept Stories that fully meet the Definition of Done. Stories that don’t meet the full Acceptance Criteria should be not be accepted unless the pending work is cosmetic or considered minor – in which a negotiation between the Team and PO will occur.
  4. Stakeholders may also be invited to the Sprint Review to view the completed Stories.
  5. The Team gives a demo and overview of the Stories completed in the Sprint.
  6. Team members should demo their work to the Product Owner and any present stakeholders. However, stakeholders should refrain from asking questions until the demo is completed.
  7. Stakeholders should provide feedback as necessary.  Feedback will be filtered and prioritized into the Product Backlog by the Product Owner. Product Owner is responsible for collecting the feedback. However, the Scrum Master can also assist as needed.

Output:

  1. Story Acceptance.
  2. Product Owner & Stakeholder Feedback.
  3. Updated Release/Version Report (automated in JIRA).

Note: If the PO can accept Stories in real time, that would be preferred and the Scrum Master will schedule the Review with the PO and Team member(s) that worked on the Story.
Note: Demos should be showcased on the QA or Staging environment from an integrated build.

Sprint Retrospective(on the last day of the Sprint, at end of day)

Attendees: Product Owner, Scrum Master, Team.

At the end of the Sprint, a Sprint Retrospective ceremony should be conducted to review the Sprint with the Team and Product Owner. This ceremony should be timeboxed between 1 to 1.5 hours depending on the scope of issues to be discussed. The Sprint Retrospective meeting should follow the below guidelines:

Input:

Sprint Summary Report from JIRA and last Sprint Retrospective notes.

  1. Scrum Master reviews the Sprint Summary to recap the Team’s performance. The Summary readout should not be more than 5 to 7 minutes.
  2. Scrum Master gathers the team’s input on what worked well, what didn’t work well, and what can be improved for future sprints. Scrum Master should be empowered to use gamification techniques to engage the Team (refer to www.innovationgames.com).
  3. Team and Product Owner should vote on top issues (dot voting is a popular technique – each person gets 3 dots and they can apply those dots on the issues that are most important to them. For example, 3 dots on one issue, 1 dot on each issue, or 2 dots on one issue and 1 dot on another).
  4. Root cause analysis should be performed on the top issues by using techniques like Fishbone analysis.
  5. Develop a plan based on the root cause analysis to address the top issues that were selected for improvement. Technical Stories can also be created and prioritized in the Backlog.
  6. Scrum Master facilitates an Agile Maturity Assessment with the Team and Product Owner once a quarter or release (described in detail in the Agile Maturity Assessment section of thethe Playbook).
  7. Now and then, the Scrum Master should use the Retrospective ceremonies to celebrate the Team’s accomplishments.

Output:

  1. Scrum Master captured what worked well, what didn’t work well, and what needs to be improved.
  2. Prioritization of what needs to be improved.
  3. Root cause analysis on how to improve on the most critical issues.

Note: For remote team members, it is important the Scrum Master utilizes a screen sharing service, such as WebEx, to share his or her screen.
Note: For improvement opportunities that are dependent on people outside of the Scrum Team, the Scrum Master should coordinate with the external person/group to ensure the improvement is implemented/completed.

Scrum in a Nutshell

Scrum in Nutshell

Scrum in Nutshell

Scrum in Nutshell

Scrum in Nutshell

About Me

Sed pellentesque nibh enim, quis euismod enim lacinia nec. Phasellus quam diam, semper in erat eu. Consectetur adipiscing elit. Sed pellentesque nibh enim, quis euismod enim lacinia nec.