Sprint Planning – Requirements & Tips

Requirements of a Sprint Plan & tips to make it easier and more effective to do Sprint Planning.

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:

• Sprints – Requirements Before You Start – Covers things you need to do before you get to Sprint Planning.
• VSTS Product Backlog Hierarchy 
• Scrum Roles & Responsibilities
• Agile PM book – Chapter 8: Planning Releases and Sprints > Sprint Planning, location 3777.
• Scrum Guide – Scrum Events > Sprint Planning, page 9.
• Certified Scrum Master (CSM) Class – Slides 71 – 80

Guidelines:

Some guidelines for having the most effective Sprint Planning activities.

Length of Meeting:

• Time boxed
• 2 hours for each week in Sprint

Sprint Length	Sprint Planning Meeting Length
1 week	2 hours
2 weeks	4 hours
3 weeks	6 hours
4 weeks	8 hours

Learn More About Length of Meeting:

• Agile PM book – Chapter 8: Planning Releases and Sprints > Sprint Planning > Figure 8-10: Sprint planning meeting to sprint length ratio, location 3844.
• Certified Scrum Master Class slide 75

Facilitators:

• Scrum Master
  • Schedules meetings.
  • Facilitates the meetings.
• Scrum Product Owner
  • Provides team with ranked Product Backlog.
    • That takes the form of ranked and well groomed Features in VSTS.
  • Helps team define the Sprint goals.

Scheduling:

• First activity on the first day of the Sprint.
• For example, finalize your Sprint no sooner and no later the Wed morning of the first day of the Sprint.

Team Should Do Story & Task Breakdowns:

• Encourages ownership by team members.
• Empowers the team to self manage and self organize.
• Team members know the most about the work that needs to be done, and therefore are the best qualified and will produce higher quality plan and Sprint Backlog.
• Scrum Master and Scrum Product Owner should only facilitate and help the team the breakdowns.

Checklists for Auditing Sprint Plan Data:

Short checklists to help make it easier to keep your data in good shape.

Start of Sprint & Daily Scrum Checklist:

Run through this checklist in the Sprint Planning meeting.  And keep an eye on this every day in your Daily Scrums.  Make sure that all work items have:

1. Area Path = team’s Area Path.
2. Sprint (Iteration Path field) = active Sprint.
3. All Stories & Bugs have:
   1. Story Points
   2. Assigned To – so it’s clear who the go to person is for it
   3. Release Version
4. Tasks have:
   1. Remaining Work and Original Estimate start the Sprint with the same hour estimate.
   2. Assigned To, if you are doing capacity planning by person.
   3. Remaining Work and Completed Work on Tasks worked on, are updated each day.
5. Check to make sure all work items have parents.  
   (All work items below the top level work item type require parents.)

End of Sprint Checklist:

Run through this checklist on the end date of each Sprint.  Make sure that all work items have:

1. Area Path = team’s Area Path.
2. Sprint (Iteration Path field) = current Sprint.
3. Work flow State = Closed.
4. Closed Date is in the Sprint.
5. Assigned To is set – so you can look back and know who worked on work items.
6. Check to make sure all work items have parents.  
   (All work items below top level work item type require parents.)
7. Roll State updates, up the backlog hierarchy.
   Since VSTS cannot automatically roll workflow State updates up to parents, you need to do it manually.  IE.  Update Feature State, based on Story/Bug children.  Update Epic State, based on Feature children.  Etc.

Sprint Planning Requirements:

These are VERY IMPORTANT and are required for Sprint Plans and reporting to work correctly.  

Avoid These Data Integrity Issues:

Not following these requirements will result it data integrity and data quality problems that will cause reports, inside VSTS and outside via Power BI or other tools, to not work correctly.  Because many different reports and metrics are all based on some of these VSTS fields:

• Sprint (Iteration Path)
• Area Path
• Workflow States
• Closed Date (set when moved to workflow State = Closed)
• Activated Date (set when moved to workflow State = Active)
• Story Points
• Work Item Type
• Task > Remaining Work

Reports such as:

• Sprint Planning Precision reports
• Sprint Velocity reports
• Burndown Reports of Releases, Tiles, Themes, Epics & Features
• Sprint Burndowns
• Other reporting based on the fields listed above

Close Out Sprint Plan Before Sprint Ends:

• Close all Stories, Bugs & Tasks before the Sprint end date.
• Otherwise, reporting inside VSTS and outside via Power BI or other tools, will not work properly.
  • For example, if you do not close a Story in the Sprint you actually finished it, your team will not get credit for closing it in some reports and metrics.
• The work item’s Closed Date must be within the Sprint (Iteration Path field in VSTS).
  • Closed Date >= Sprint Start Date AND Closed Date <= Sprint End Date.
  • If it is not, it will not appear on some reports.  Effectively, it will vanish and your team will not get credit for closing it.  You’ll then have to manually tweak the metrics and other data outside of VSTS and Power BI.
• If your team forgets to close a work item on time, before the Sprint ends, you will need to change it to the next Sprint that is open and active.  So that the Closed Date is within the Sprint (Iteration Path field in VSTS) that is on the work item.
• TIP:  Add Closed Date field to your views and queries.

Sprint (Iteration Path field) Must Be Correct:

• Sprint (Iteration Path field in VSTS) must be set to the Sprint that the work item is planned in.  And when it’s closed, in the Sprint it is closed in – change it if needed.
• TIP:  Add Iteration Path and Closed Date fields to your views and queries.

Area Path field Must Be Correct:

• Area Path on all work items in a Sprint must be set to your team’s.
• TIP:  Add Area Path field to your views and queries.

Never Move Backwards in the Workflow:

• Never move a work item back a step in a workflow.
  For example, never move from Active back to New.  Or from Closed back to Active or New.
• This is also critical for reporting to work properly.

Never Skip a Step in the Workflow:

• Never skip a step in a workflow.  
  For example, never move from New directly to Closed.
  1. First move it from New to Active.
  2. Save it.
  3. Move from Active to Closed.
• Always save between each step.
• This is also critical for reporting to work properly.

Never Change Story Points After Sprint Starts:

• Once the Sprint starts, never change the Story Points ever again.
• You can change the Story Points at any time you want, all the way up to the Story being planned in to a Sprint and BEFORE the Sprint is started.
• This is because Points are essentially to reporting, so changing them after a Sprint starts will break reports.

Complete Point Estimates Before Sprint Starts:

• Enter Story Points on Stories and Bugs in VSTS, BEFORE the Sprint begins.
• Note, that this does not mean that all future Stories/Bugs need to be estimated in Story Points before the first Sprint can start.  However, until all work in a release is estimated, reporting that projects when work can be completed, is not possible.

Never Change Work Item Type After Sprint Starts:

• After the Sprint starts, do not change the Work Item Type of a Story, Bug or Task, in the active Sprint.

Make Sure Work Items Have Parents:

• Check to make sure all work items have parents.  
  (All work items below top level work item type require parents.)

Do Not Remove Work Items That Have Been Started:

• DO NOT change any Work Item whose State is Active or beyond, or has children whose State is Active or Beyond.
• You cannot remove something, if work has already started.

Sprint Planning Tips:

Draft Your Sprint Plans In Advance:

• Have Backlog Grooming and Sprint Plan drafting meetings with your Scrum team before the next Sprint, to load a future Sprint with some Stories ahead of time.
• This will save you a lot of time at the end of the Sprint and beginning of the next, when there are lot more things to do.  IE.  Sprint Reviews, Sprint Planning, Sprint Retrospective all happen at the end and beginning.

Groom Your Backlog:

• Continuously groom your backlog.  Meaning add more and more details to your team’s Features and Stories.
• Have regular grooming meetings – at least weekly.
• Make sure to detail the requirements in the Description field, and also detailing the Acceptance Criteria.

Document Complete Acceptance Criteria:

• Acceptance Criteria should be detailed enough, for anyone to be able to determine if the work is complete.
• Use Acceptance Criteria as the basis of accepting a work item as complete, and Closing it.

The Scrum Team Decides What to Accept in or Reject from their Sprint Plan:

• Scrum team members should reject working on a Feature, and reject putting a Story or Bug in a Sprint Plan, until it has a complete Description and Acceptance Criteria.
• Remember, the Scrum team and individual team members get to decide what goes in their Sprint, and what does not.  So they have the final decision on whether to accept or reject a Story/Bug.
• So that’s another reason why documenting complete requirements in Description, and also detailing the Acceptance Criteria is very useful and important.

Closing Work Items:

• Don’t Close a work item, until the work passes the Acceptance Criteria.
• The Scrum team member in the Assigned To (the go to person) of a Story/Bug can determine when it is acceptable and can therefore be Closed.  
• Scrum Product Owner has the final decision on whether a Feature can be Closed.
• So that’s another reason why documenting complete requirements in Description, and also detailing the Acceptance Criteria is very useful and important.

Make Titles Short but Descriptive:

Update Titles to make it short but descriptive – 5 to 10 words. Makes it readable & useful on board views, reports, etc.

How To Set Column Options:

1. In a Backlog view, click Column Options button.
   
2. To add, select columns from the Available columns list on the left & click the > button to add.
3. To remove, select columns from the Selected columns list on the right & click the < button to remove.

Suggestions on useful fields to display in columns:

In Sprint views:

• ID, (Optional: Work Item Type or use color coding), Type, Title, State, Assigned To, Story Points, Remaining Work, Area Path, Iteration Path

In Stories views:

• ID, (Optional: Work Item Type or use color coding), Type, Title, State, Story Points, Area Path, Iteration Path

Notes:

• Column Options are your personal settings, so only you will see these settings
• Settings are different for every Backlog view