DRAFT

This is a port of some specific flows, and not generalized sufficiently to become common practice, but posted at this time for its informational value.

SPRINT PLANNING

Part 1

Success = leaving the sprint planning meeting committed to completing a list of stories.

+ we set a high level sprint Goal: a one-sentence description of the overall outcome of the sprint.

During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the Product Backlog into the more detailed tasks of the Sprint Backlog.

The product owner comes to the meeting able to describe about 2 sprints worth of desired stories (top 20). The team’s objective is to understand the stories from the product owner’s point of view, to share in the product owner’s vision. The ScrumMaster should ensure that the team is asking enough questions and capturing all of the resulting data, including acceptance criteria, sketches, and any assumptions.

The team might have additional questions for the Product Owner after it begins to break the questions down into tasks to create a sprint backlog.

The Sprint Backlog captures all of the stories, notes, acceptance criteria, tasks, and estimates for a particular sprint.

Once estimated,  we evaluate capacity (against the burn rate), trying to leave room for emergent tasks

Part 2

The team discusses how to implement a story and estimates tasks.

The product owner must be available via IM  for clarifying questions during this meeting but does not have to be in the room. We actually prefer it that way.

Here we develop the functional tasks that will make up the sprint and estimate them in hours.

The output of the second planning meeting will be the Sprint Backlog.

RELEASE PLANNING (BACKLOG GROOMING)

The product owner meets with the Solutions Architect to discuss stories coming up in the product backlog. The product owner will share the current known priority and may ask the team for help in determining the relative cost and risk associated with any new items or items for which more is now known. The Solutions Architect is also asked to give input on the sequence of the work and is encouraged to suggest ways to optimize the order in which work is done.

New stories are estimated using story points. Story points tell us how big a story is, relative to others, either in terms of size or complexity.

BACKLOG PRIORITIZATION

Product backlogs must be prioritized based on business value and risk.

Anyone may add items to the product backlog at any time, but only the product owner may prioritize them.

ESTIMATING

Fibonacci is the sum of the previous two numbers: 0,1,1,2,3,5,8,13,21,34,55…

We use a modified Fibonacci sequence: 0.25,0.5,1,2,3,5,8,13,21

Points are relative, not fixed. They don't directly map to hours in the Product Backlog.

Estimates on tasks in the Sprint Backlog will be in hours.

We want our stories to be assessed against I-N-V-E-S-T criteria for quality:

•  Independent (of all others)
•  Negotiable (not a specific contract for features)
•  Valuable (producing value for the product owner, or is providing incremental vertical improvements)
•  Estimatible (to a good approximation)
•  Small (so as to fit within an iteration)
•  Testable (in principle, even if there isn't a test for it yet)

see https://www.agilealliance.org/glossary/invest/ & https://www.scrumalliance.org/community/articles/2014/january/the-invest-scale for more info

Planning Poker

1. The ScrumMaster presents the top item in the product backlog to the team.

2. The team discusses what the story is.

3. The product owner clarifies questions, assumptions, and unknowns—as well as acceptance criteria.

4. Each team member privately decides how big this story is relative to a reference story, a series of reference stories, or all of the stories on the product backlog.

5. At the count of three, everyone shows his or her chosen "card" simultaneously (story point value).

If everyone played the same card, the team can log the estimate and move on to the next story.

If there is a wide variance (for instance, the displayed numbers range from one to eight), then the team spends time discussing the story. To focus the discussion, have the low bidder and the high bidder both explain their reasoning for their estimates. The conversation is valuable here, not the number, because that’s where the learning occurs and any assumptions are uncovered. After a brief 30-second to one-minute discussion, the team repeats steps 4 and 5. This continues until the team agrees on an estimate for the story.

EXAMPLE SPRINT SCHEDULE

This is an example sprint schedule in 2 week iterations

[we will need to groom the backlog as part of the first sprint planning to kick this off]

• SPRINT PLANNING 1 + 2 (Wed)
• STANDUPs will occur Tues + Thurs (15m)
• BACKLOG GROOMING meeting the second Mon (before the sprint end)
• PRODUCT DEMO at sprint end, includes stakeholders
• RETROSPECTIVE at sprint end
  
  

Resources

• Agile Manifesto Principles: http://agilemanifesto.org/principles.html
• High level explanation of Agile/Scrum terminology: http://www.mitchlacey.com/intro-to-agile/scrum
• MSDN Application Lifecycle Management whitepapers:
  1. Estimating  http://msdn.microsoft.com/en-us/library/hh765979.aspx
  2. Prioritization http://msdn.microsoft.com/en-us/library/hh765981.aspx