Sprints – Requirements Before You Start

Lists requirements for Scrum teams before starting a Sprint, and before a new Scrum team starts their first Sprint. 

Written in 2016-2017:
This is part of a series of articles that I originally wrote in 2016-2017 and were only published on private internal company wikis. I am publishing them publicly for the first time in 2019, here on my blog.

Written for Microsoft’s VSTS:
Some content is written for Microsoft’s Visual Studio Team Services (VSTS), as it existed in 2016-2017. VSTS was renamed to Azure DevOps in 2018 (WikiPedia).

Learn More:

• Sprint Planning Requirements & Tips 
• Estimating Story Points using Affinity Estimating 
• Sample Story Pointing Scales below.
• Estimation Poker or Planning Poker Tips 
• Writing & Breaking Down Tips for Features, Epics, Stories, Etc. 
• Gaining consensus with the Fist of Five in Agile PM book – Chapter 6 Putting Agile into Action: The Behaviors > Establishing Agile Roles > Gaining consensus: The Fist of Five, location 2573.

DO NOT start a Sprint without these done:

1. All the Stories & Bugs that your team plans to work on, in your Sprint Backlog in VSTS.
2. All Stories & Bugs with Story Points estimated.  
3. Task breakdowns on all Stories & Bugs, with time estimates in person hours.

Otherwise, reporting inside VSTS and outside via Power BI or other tools, will be not work properly.  For example:  Sprint Burndowns, Velocity reports and lots more.

Things To Do Before ALL Sprints Start:

Break down enough Stories to fill the Sprint Backlog:

1. Break your top ranked Features, into Work Stories.
2. 1 Person, 1 Sprint, 1 Story guideline:
   • Try to break the Stories down so they are small enough to be complete by 1 person in 1 Sprint.  Or smaller.  
   • Smaller is better because they are easier to describe, easier to estimate, and easier to complete.
   • They do not need to be completed by 1 person, just be no more than 1 person’s worth of time.
   • Multiple people can work on 1 Story.
   • Remember that only on a Task, can only 1 person work on it.
3. Put them in your Sprint Backlog in VSTS.

Estimate Story Points for the Stories in Sprint:

• If you are able to do an Affinity Estimating workshop (see Estimating Story Points using Affinity Estimating), then do that.
• Otherwise you can use Estimation Poker – see Estimation Poker or Planning Poker Tips.
• Or you can use consensus building.

Assigned To is Filled In:

• The person Assigned To is the one responsible for:
  • Feature  =  Driving the Story breakdown with the team, and driving it to Closed.
  • Story & Bug  =  Driving the Task breakdown, and accountable for driving it to Closed.
  • Task  =  Completing the Task.
• TIP:  Add the Assigned To field to the columns of all of your personal list views & queries.

All Stories, Bugs & Tasks in your Team’s Area Path:

• This is essential for VSTS reporting and views to work properly.
• TIP:  Add the Area Path field to the columns of all of your personal list views & queries.

Task Breakdowns on All Stories & Bugs:

• Only 1 person can work on a Task.
• Estimate work effort on each Task in person hours.  
• Enter estimated hours in Original Estimate field & Remaining Work field.  Never change Original Estimate ever again.
• As you complete work, add the hours worked to Completed Work field.  It is OK if the total is more or less than the Original Estimate.
• Adjust the Remaining Work field as work is done.  It’s OK if you need to increase it.

IMPORTANT NOTE:  The VSTS Sprint Burndown reports and dashboard widgets built in to VSTS, are dependent on Task breakdowns and the time data in the Remaining Work field to be update DAILY.  If all Stories & Bugs in a Sprint are not broken down, and Remaining Work data updated every day, these reports will be broken and useless.

Things To Do Before Sprint 1 Starts:

Determine a Story Pointing Scale:

If you do not have enough Stories broken down to do an Affinity Estimating workshop (see Estimating Story Points using Affinity Estimating) and get a consensus on a scale there, this can be a good alternative.

To get consensus with your team on your team’s Story Pointing Scale.

• You could ask the team “How many Points should a Medium or average sized Story be ?”.  
• You could consider a medium is no larger than 1 Person, 1 Sprint worth of work.
• Remember you’ll need room on the point scale, on each size of Medium, for the other T Shirt sizes.
• The other T Shirt sizes simply fall in to place, after you get consensus on a Point value for Medium.
• See sample Story Pointing Scales below.
• DO NOT CHANGE your team’s Story Pointing Scale for the live of the product release because projections require a consistent pointing scale for a team.

Sample Story Pointing Scale that you can copy & adjust:

Your team should workshop estimating to determine your preferred pointing scale.  Don’t simply copy this one.  Use this as a template only.

Get a Team Wiki space:

Create a Wiki space for your Scrum team in your internal wiki.

Share your Story Pointing Scale in your Scrum team’s Wiki space:

• You can copy the sample above and edit it.
• Share it directly in a widget or tile, on the Overview page of your Scrum team’s Wiki space.

Consensus Building:

1. Each person can vote for a Point value.
2. Each person not in the majority should be asked to explain why they voted for the value that they did.
3. Everyone votes again.
4. Repeat until the team agrees that they have a consensus on a point value.

You could also use the Fist of Five technique to gain consensus: 

• Gaining consensus with the Fist of Five in Agile PM book – Chapter 6 Putting Agile into Action: The Behaviors > Establishing Agile Roles > Gaining consensus: The Fist of Five, location 2573.