Roles Artifacts Meetings AGILE CHEAT SHEET *Estimating Scrum Team Product Backlog - (PB)

Product Owner - (PO)

Scrum Master - (SM)

SYNERZIP

Scrum teams are self organizing.Team is cross-functional and consists of 5-9peopleThere are no set project roles within the teamTeam defines tasks and assignmentsUsually Dev : QA ratio is 3:1. Team develops the product as per sprint backlogEnsures team works on highest valued features

Accountable for product successDefines all product featuresResponsible for prioritizing product featuresMaintains the Product BacklogEnsures team works on highest valued featuresOne full time product owner for every scrum team

Holds daily 15 minutes team meeting (Daily Scrum)Removes road blocksFacilitates planning and estimationMaintains the Sprint Burndown ChartConducts Sprint Retrospective at the end of everySprintMaintains team spiritTypically one scrum master can handle two scrum teams

TDD = Refactoring + TFD

XP - Extreme ProgrammingTDD - Test Driven Development, Routine RefactoringBDD - Behaviour Driven DevelopmentTFD - Test First DevelopmentCI - Continuous IntegrationCD - Continuous DeploymentUAT - User Acceptance Testing

Maintained by the Product Owner List can contain bugs, and non-functional itemsProduct Owner responsible for prioritizingItems can be added by anyone at anytimeEach item should have a business value assignedList of all desired product featuresProduct backlog can be organized as a prioritized listof user stories in order of “high-risk, high-value”, “low-risk, high-value”, “low-risk, low-value”

To-do list (also known as Backlog item) for the SprintCreated by the Scrum TeamProduct Owner has defined as highest priority

Chart showing how much work remaining in a SprintCalculated in hours remainingMaintained by the Scrum Master dailyMaintain seperate account of work remaining out of the “Original RB” and “New Features” added during the release

Same as the Product Backlog. May involve one ormore sprints dependent on determined Release date

Sprint Backlog - (SB)

Burndown Chart - (BC)

Release Backlog - (RB)

“DONE”= Potentially Shippable!

FAQ

Who decides when a Release happens? At the end of any given Sprint the PO can initiate a Release.Who is responsible for managing the teams? Theteams are responsible for managing themselves.What is the length of a task? Tasks should take no longer than 16 hours. If longer then the task should bebroken down further.Who manages obstacles? Primarary responsibility is on the Scrum Master. However, teams must learn to resolve their own issues. If not able then escalated toSM.What are two of the biggest challenges in Scrum?Teams not self-managing, Scrum Master manging not facilitating.How to add new User Stories to SB in the middle ofsprint? Its not advisable. Sprint should be short enough to allow new user stories to wait till the next sprint starts. In exceptional cases a new user storycan be added by removing one or more stories tokeep the total of story points constant.

Sprint Planning - Day 1 / First Half

Sprint Planning - Day 1 / Second Half

Daily Scrum

Sprint Review

Sprint Retrospective

Visibility + Flexibility = Scrum

Kanban

Product backlog prepared prior to meetingFirst half - Team selects items committing to completeAdditional discussion of PB occurs during actual Sprint

Occurs after half done - PO available for questionsTeam solely responsible for deciding how to buildTasks created / assigned - Sprint Backlog produced

Held every day during a SprintLasts 15 minutesTeam members report to each other not to Scrum MasterAnswers 3 questions during meeting“What have you done since last daily scrum?”“What will you do before the next daily scrum?”“What obstacles are impeding your work?”Opportunity for team members to synchronize theirworkHaving daily scrum over a conference call in distributed teams is not advisable.Distributed teams are advised to break in multiplecolocated teams.

Team presents “done” code to PO and stackeholdersFunctinality not “done” is not shownFeedback generated - RB may be reprioritized.Scrum Master sets next Sprint Review

Attendees - SM, PO and Team.Questions - What went well and what can beimproved?SM helps team in discovery - does not provideanswers

Applies to any process that has sequence of stepsWIP-Limit - maximum WIP allowed at any step isfixed. WIP-Limit can be quantified in Story Points.Typical steps - Requirement clarification, development, integration, testing, deployment, UATAdd or move resorces to wherever the bottleneck isobserved. Of course, the bottleneck may keep moving.Works well for ongoing support/maintenance work.

High level definition of user requirementsthat serves as a starting point for discussion. Building blocks that can be assigned priorities, estimates, completion status.Large user stories (Epics) that take longer than a sprint to build are broken into smaller user stories.User stories are NOT dependent on other storiesStory Template: “As a <User> I want <function> So that <desired result> Story Example: As a user, I want to print a recipeso that I can cook it.

Testing and AutomationManual QA and Dev are co-located, and in 1:3 ratio,for new products. Automation QA team is separate. Continuous testing using automation for early defectdetection. Automation lags by a sprint to allow recent test cases to stabilize.

* Inspired by ScrumLogic

Testing via xUnit Framework Cards bearing Fibonacci numbersare distributed to all team menbers. Story is discussed and team members put down the card estimating the points for each the story. Cards are opened and the highest and the lowest bidder debate to support their estimate.It is repeated till team converges on the estimate.

The rate (Story Points per Sprint) at which team converts items to “DONE”. After a few iterations velocity becomes stable and predictable

Story points indicate relative degree of difficultyand they follow the Fibonacci series because it represents a set of numbers that we can intuitivelydistinguish between them as different magnitudesExample: ”Send to a Friend” Story Points = 2“Shopping Cart” Story Points = 8“Advanced Search” Story Points = 13

User Stories

Planning Poker

Business Value

Story Points

Velocity

Each User Story in the Product Backlog should havea corresponding business value assigned.Typically assign (L, M, H) Low, Medium, HighPO prioritizes Backlog items by the highest valueUser Stories can be classified as “Must have”, “Should have”, “Could Have”, “Good to have”

Refactor code[Test(s) broken]

Refactor code[tests unbroken]

Fix Functional code

Write a test

Can’t think of any moretests

All TestsPass

One or moreTests fail

1

2

3b

4

3a

Refactor code[tests broken]

XP Practices

www.synerzip.com