The new bug model in Scrum for Team System 3.0 might look obvious at first, but it's taken a long while getting to where it is. Before I start delving into how the new bug model works, it's worth taking some time to describe what came before it.
Almost by coincidence, each of the three major versions of Scrum for Team System have had a different bug model, this represents both an evolution in how teams are becoming more Agile as well as a reflection of how powerful and expressive TFS is becoming as an ALM meta-process platform.
NOTE: It's worth noting that although VSTS itself only gets hierarchical work items with 2010, we've always modelled a pseudo hierarchy with our process template. Some people took to it, others didn't. Everybody however understood with the release of Task Board for Team System however, because that visualised the parent - child relations between the work items. Please keep in mind when I'm talking about 2005 and 2008 that there was always a "conceptual" parent child hierarchy even thou this wasn't explicitly enforced or supported by TFS at the time.
Version One for TFS 2005
The Version One series was our first attempt at a process template and was purely designed for our own in house use (Conchango having discovered Scrum in about 2003 through consultants still with us today such as Howard van Rooijen and Stuart Preston and of course our ex-CTO lately Global Head of Agile Colin Bird).
For Version One, it was decided that developers during the Sprint would either be working on new work (SBI's) or fixing broken existing work (Bug's) - and so it seemed logical to have Bugs as "children" of Product Backlog Items (PBI's)
It looked like this:
And people accepted it readily. Mainly because it mapped to what they were already doing. Testers could raise bugs against PBI's and assign them to developers.
If you wanted to raise an "out of Sprint" bug - for example one raised by a customer, you were supposed to create a new PBI in good Scrum fashion, but because the hierarchy was implied and not actual, a lot of people just used the Bugs as they came.
It's also worth noting that back in 2005, this was a process template in the true sense of the word, some people used it as was (because it was complete), but many people modified before using it on a real project.
Version Two for TFS 2008
By 2008 Conchango was pleasantly surprised by the external take up of the template and was keen to produce something for the forthcoming TFS 2008 - and let's just say that Microsoft was enthusiastic for us to do so too!
The Iteration Path was now available for use by 3rd party templates so it felt time to re-address the general implementation of the template.
One of the key areas troubling Colin at the time was that the existing bug model wasn't "very Scrum". Experience had shown that it encouraged people to raise bugs "in sprint" instead of talking to each other. So he took the existing model and flipped it on it's head.
Taking the Scrum mantra of "bugs are prioritised by the Product Owner along with all other work" to heart he "promoted" bugs to the PBI level and worked out a "Scrum Pattern" for how the team would work on In Sprint bugs.
So we went from the model shown above to the following:
Which resulted in Backlogs that looked like this:
So this was great for Product Owners and for bringing into TFS Bug sightings from customers. It also gave projects the much prized single work stream of new features and bug fixes. Finally Scrum for Team System was pure Scrum.
But what were you supposed to do if you found a bug in the middle of a sprint?
This is where the "Ready for Test" state on the SBI (Sprint Task) was born. This state allowed teams to decide which Sprint Tasks were testable and which were not - and thus "self organise" and trust each other to do the right thing (or put more simply, "Do Scrum").
Teams were meant to "iterate" backwards and forwards between In Progress and Ready for Test on their Sprint Tasks until they were at the required quality to be considered releasable as a potentially shippable increment of code. It looked something like this:
So this was great for Scrum teams and a nightmare for Scrum-butters.
It wasn't perfect however, although I've worked with many teams who really "got" this way of working, where I personally ran into problems with this approach was when the test resource was off shore and more significantly in a different time zone, or in the dreaded "works on my machine" syndrome. Modern software is complex and often difficult to debug, so I felt the need for a "richer payload" during the Sprint - even sometimes just to remind *Myself* of problems that I'd found, so I could reset my context the next day.
I was feeling the need for the ability to raise a bug in-sprint, but the agilist in me knew it was wrong. I also knew that adding back in an in-Sprint bug type had the real potential to mess up a team's ability to develop good and productive agile practice if their old fall back of raising a bug rather than working together to complete the PBI was sitting in the corner making beckoning motions.
So I started to think...
Version Three for TFS 2010
The bug model you see in 3.0 was in fact originally destined for Version 2.3 however it's implementation is far richer in 2010 and so we've focused on that first. You'll see 3.0 come out into production before you see 2.3 released (unless we hear some demand for us to do otherwise)
Shortly after the launch of 2.2 was when I started to get fully Test Obsessed and becoming a hard task master about always always always having Acceptance Tests on Backlog Items, especially those utilising User Stories. The payoff for this discipline was amazingly good, and so I began on a quest to add a new Work Item Type to Scrum for Team System - the Acceptance Test.
Previously, Backlog Items in Scrum for Team System had a free form plain text field for "Conditions of Acceptance" - which was a nod to Mike Cohn's "Conditions of Satisfaction" which was his attempt to make the term "Acceptance Tests" more palatable to those business types who woke up one morning to find themselves as Product Owners. So technically we had it covered.
The problem was, that it was a bit invisible and you couldn't really do anything with it. I wanted something stronger; something I could report on, something I could see and something that I could have red and green flashing lights on to let me know what was going on. Nothing but a WIT was going to cut it.
In my mind and on my prototype, In-Sprint Bugs then became "Failures" which was something an Acceptance Test could have, and it was good. (But not released)
At about this time I went to PDC 2008 in Los Angeles as a guest presenter with Lori Lamkin and Sunder Raman from Microsoft (there is a video on Channel 9 if you look hard enough) - on Agile Software development - and I saw TFS 2010 for the first time.
So from that point it became clear, Product Backlog Items were to be "tested by" Acceptance Tests and Acceptance Tests were to be "failed by" Bugs.
Using TFS 2010 named linkages we get the following:
So why Bug Report?
If you've stuck with me this far the answer should hopefully be obvious. In Version One, Bugs were Sprint Backlog level Work, you could assign hours to them and burn them down. In Version Two, they were Product Backlog Level Work, you could story point them, assign Sprint Tasks to them which could then burn down. But in Version Three, they're just Bug Reports - they optimised to let you capture all the information about a Bug, but you can't "do" them, like you used be able to "do" both previous "bug" types, it's for this reason that we now refer to them as "Bug Reports" (even if your copy of Beta 1 says, "Bug" for which I apologise!)
I'll explain more on how to actually use the 3.0 QA system in the next post.