Scrum for Team System Tips

As I'm staring at my blank Team System setup waiting for the system to work again, I thought I would share a few Scrum for Team System tips with you. SFTS has done a pretty good job for us (much better than the stock templates Team System comes with) but it does have it's issues and problems (like the fact that PBIs are expressed in days and SBIs are expressed in hours, totally messes up with the Scrum concept and makes PMs try to calculate "hours per point"). I'm really digging Mingle though and will be blogging more on that as we're piloting it for a project right now and I'm considering setting up a public one for all of my projects (it's just way simpler than Rally, VersionOne or any other Agile story management tool on the planet, hands down). 

• When a sprint ends, all outstanding PBIs should be moved to the next sprint and the sprint marked as done.
• The amount of work done in the sprint (SBIs completed) gives you the capacity (velocity) for the team for the next sprint.
• Only allocate one sprints-worth of PBIs to a sprint when planning and try to estimate better based on previous sprint data.
• When the customer decides the product is good enough for shipping have a release sprint where the goal is to "mop up" bugs and polish the product ready for shipping. This would include new PBIs like:
  • Fix outstanding bugs
  • Create documentation
  • Package/create MSIs
• Never attach new SBIs to previously closed PBIs. If the customer changes his mind about the way something is implemented, it is recorded as a new PBI because the requirement has changed.

Definitions:

PBI: Product Backlog Item, can be functional requirements, non-functional requirements, and issues. Comparable to a User Story, but might be higher level than that (like a Theme, depends on how you do Scrum)

SBI: Sprint Backlog Item, tasks to turn Product Backlog Items into working product functionality and support a Product Backlog requirement for the current Sprint.