Thursday, August 27, 2015

How TFS 2013 Calculates Story points for Velocity Graphs

TFS 2013 grafts Agile on top of their traditional task model.  The TFS web interface is significantly more functional than previous iterations.

Sprint-to-Sprint Velocity

TFS Scrum and Agile templates automatically calculate per sprint velocity based on the Story Points of User Stories with the current iteration path. Setting the Iteration Path essentially commits the team to the User Story for that sprint. The following diagram shows the number of story points for User Stories committed to over the last 5 sprints.


  • Green represents story points for Completed stories
  • Blue represents  story points for Active  stories.  Previous stories can have some blue if stories were left open at the end of previous tasks.



TFS Story Point Calculation Commitment Issues

Teams commit  to certain stories in the sprint by putting them in the sprint Iteration Path.  They base the number of committed stories the sum of the story points for those stories. Many teams commit to User Stories but leave those stories in the New state until work has actually started.  This makes it easy to see which stories are being swarmed on and which ones have not yet been started.  Teams move User Stories to the Active state when work actually starts and finally to the Closed state when they meet the Definition of Done (DoD)..

TFS shows story point based velocity for only Active and Completed User Stories.  It ignores all stories in the New state.  This can make it difficult determining how many stories can be brought in during sprint planning.  Teams either have to sum the story points for User Stories on the current iteration path or they need to set all the committed User Stories to Active.

Story Points vs Hours and Stories vs Tasks

Story points represent they amount of required work based on a relative scale of the types of work in the backlog. They represent a best guess at the amount of work relative to other work. TFS story points correlate to some number of  hours but are use to avoid the common problem of false precision in estimates.. 

TFS tasks are estimated in hours. They represent a best guess at hours for general sizing. Sprint burn-down charts are based on task/hour burn-downs. Management often treats TFS task hour estimates as correct when the reality is they are best guess estimates.