Article: XP and Triage

XP and Triage by Nancy Van Schooenderwoert

This article is about Extreme Programming and Triage for two reasons:

1. If I had to pick the top benefit that XP has yielded my team it's the natural "requirements triage" it forces on both management and developers.

2. A widespread, growing problem in software development is the disconnect between the software developers and those who sponsor the development activity. Mistrust leads the sponsors to inflate the importance of features requested and to demand completion in a very short time. They fear that it's the only way they will end up with something usable in a timeframe that they can live with. The solution to this problem is for both sides to acquire some negotiation skills.

Extreme Programming gets at the root of this insidious problem by giving the development people an acceptable way to tell menagement when something *really* cannot be done. It also gives management a way to keep the developers from running away with the project. We've all seen projects where the feature set gets driven inappropriately by the developers - they'll decide to add cool features because they expect it to be easy to do, or they are sure the users will want these extras.

Here's how the Planning Game works: There are two players, Business and Development.

The goal is to maximize the value of the software produced by the team, while minimizing the cost (effort) and the risk involved. The method of playing this game centers around "story cards". They are brief descriptions of each "story" or "feature" that is desired. Anyone can originate an idea for a new story, but only 'Business' gets to say which will be implemented. But they cannot dictate the schedule, except when they are willing to cut scope. It's for 'Development' to say how much effort and risk are associated with each story. This interaction takes place at the planning of each software release. You can plan longer term, covering several releases if you choose. Only you cannot do it in detail, according to XP. You should just do a rough plan for events that are months or more away because the details will change anyway.

I'll give an example of a Planning Game session that occurred with my own team. There were six features that 'Business' wanted - we had informally discussed them beforehand. Prior to meeting with our project manager who was acting in the 'Business' role, we looked at the code to map out a detailed design of how we'd implement these features (taking a day or two at most). We didn't write up any extensive design info. We just noted which existing functions and modules would be changed, and what new ones would be created. We also noted any changes to data structures, especially those shared between modules or other interfaces. Then we assigned points estimates to each feature. Our team had been doing 4.5 points per week in previous work, and so depending on the due date, we wanted to commit to the same level of effort.

When we met with our project manager, he wanted the release by a certain date - there would be only seven work days to do these features. The points total was 7.5 - clearly impossible by our latest demonstrated capability. So we asked him to pick a feature that could be delayed to the next release. We could have proposed a change to one of the features to make it less effort, but in this case it made most sense to delay one feature. That reduced the points total to 5.5, and 7 days is 1.4 work weeks, so we were signing up to 3.9 pts/wk (i.e. 5.5 points divided by 1.4 weeks). The resulting agreement we made is listed below.

Statement of work, in order of priority

Who	Points	Description
SL/NS	2.5	F78. Automatic Exposure Control (AEC)
NJV	0	F91. Change Filtering Pixel from 720 to 330
SL	0.5	F90. Change Filtering to Zero-out spectra if insufficient samples obtained
NJV	0.5	F83. Re-enable Filtering for Field Use
TL	2.0	F22. Add Reliability Data Check for PLD info
	5.5	Total

The points estimate is not function points. It's a measurement described in the XP literature. It's not so important what estimating technique you use as long as it is something the developers know how to apply and can use confidently (and quickly) to bid the work. One feature is estimated with zero points because it was just a change to a #define in the code and could be tested simultaneously with one of the other features.

Another thing to note is that 'Business' cannot tell 'Development' to take design or testing shortcuts. The developers accept their responsibility; it is not assigned to them. Given what is known about the planned final feature set, the developers can put the appropriate design foundations into place. XP places a lot of pressure on you to put them in place incrementally however. If you need a database to support one feature, you can bid a lot of points to fully do the database and then put the feature on top. But if there is a way to just put in as much database as you'll need for a stripped-down initial version of the feature, then you can deliver more business value for less effort. It may turn out later that the feature isn't as needed as 'Business' thought it would be so the stripped-down version of it is fine as is. Or maybe they change their mind about it altogether and drop it. The code is left in good shape if you used a legitimate (from the s/w design standpoint) way to implement an abbreviated version of that feature.

The beauty of this sort of triage is that it harnesses the creativity of the developers to do what they know best: how to take the present code base and modify it to add or change features in a way that does not introduce kludges, or other disjoint interfaces that can generate bugs. It likewise frees 'Business' to concentrate on what they know best: how to position the product feature set to appeal to the targeted users.

Suppose you're the lead software developer and you think your management doesn't know how to do their side of this bargain. You'll be ahead if you set up a clean division of labor where your software team is delivering on its promises. If it later becomes clear that your marketing folks had you do the wrong mix of features, let it be dealt with at a higher management level. Suppose you're the manager responsible for the product and you're sure the software developers are not going to finish the features you need. Your best bet is to be very clear about what is the priority ranking of the feature set, and to specify what tests the software has to pass. Even if scope ends up having to be cut, you will have the most important features finished and everyone involved will be clearer about what it takes to implement the dropped features in the next iteration.

The Planning Game is quite effective as a negotiating tool. It is very hard for developers to push back against unreasonable schedule demands because they usually have nothing management can "see" - they are just stating their opinion that the time's too short. They are often right but being right is not enough. They have to show the other side some convincing evidence. Usually there is none because there aren't any metrics. Our team started using the Planning Game by simply doing the points estimates on our own for a release we had signed up to do already. When that release was complete we then had a comparison of our estimated points and the actual points completed in x working days. That number was used as our points per week "speed" for the first official try at using the XP Planning Game process. That was far easier than instituting a big program to generate s/w metrics and history for the whole company. Something like that is hard to sell to management and can get bogged down too easily. The whole spirit of XP is to do something as simply as possible that will give value.

For negotiating, when you can say to your 'Business' player that you think their due date is too short because the folks who will implement the features have already looked at how to do it and they estimated it as being the same effort as the previous release which took 3 weeks, then it is very hard for them to counter that. How can they insist it will only take one week to do this new work? Even if the business player is the former software lead person and says they can do it in a week you can simply offer to walk through each of the individual feature estimates and the notes showing the extent of the changes. If they still claim it can be done in one week, offer to let them do it. At the very least you have good ammunition to insist that they agree to cut scope a week into the work, and you will implement the most important feature first.

The hardest thing in using the Planning Game is to make sure you deliver every release on time. You have to cut scope to do it. Cutting quality is out. Nobody wants buggy code, no matter how urgent the situation is. In some Planning Game sessions I had a hard time getting Business to say that any feature could be sacrificed, so I would draw a line across the feature list and say to them "Suppose the due date arrives and we have all the features implemented except for the ones below this line? Will you be able to use this release?" The next question is "OK, so you've said every single feature is critical - is there even one that could go below the line?" If they say no (or won't move enough of them to non-critical), then I change the order of the features in the list and say I think I've ranked them in the order of importance. Inevitably, they'll rearrange them. That's fine. I get a commitment as to which is the most important, the next most important, etc.

I then say that our metrics tell us we can safely get the first two features done (or whatever the actual number is), and getting the last 3 of them in is going to be high risk. We'll do all in our power to work diligently and test thoroughly and if everything goes without a hitch we may be able to get the other three things in but if not, then I want to meet again with you on x date to re-prioritize. This has gotten people to go along. If there truly is no chance of getting those extra three features in I don't hold out hope of it; I'll say we will do our best but since our metrics say its such a long shot then I insist that we look again at the situation on day x. How can they refuse to? Now the onus is on them to say we're not working hard or we're doing unnecessary stuff. We can show exactly what we're doing and why because of the detailed design we did as prep for the Planning Game meeting. On the good side, it gives management an incentive to make sure our time isn't wasted by needless interruptions.

The biggest reason our software got completed and is in field use now is that we practiced requirements triage. We also did sufficient design before starting to code. And we used iterative software development. I believe those three are all strong contributors to success, but without the triage the other two wouldn't have been enough. Both Business and Development have to practice triage. I have a list of all the stories that were ever seriously considered for this software, and it is at least as long as the list of stories we implemented. Some of the leftovers are features I was sure we needed. For instance we have a run-time trouble log and it's in RAM. As long as we don't have a bug that messes up the communications link we can retrieve the log. But we should store it in Flash memory so we can retrieve it no matter what. Well, that effort was always too large to get prioritized above other needs. Business understands the risk we run and they have made a judgement to live with it. This is proper - they get to decide what functionality they need and are willing to pay for. They also decide how to balance risks.

When the release work is underway, it's important to implement the most important feature first. I mean the one 'Business' has said is most important. If unforeseen problems occur then you want to be in a position to cut scope and still deliver business value. Fully test each feature as it is completed. If you have completed five of six requested features and time's up, you can offer the release to 'Business' or they can decide the date is movable, and re-plan. If they accept the 5-feature release after having insisted that no feature could be omitted, then they lose a little credibility. They will pause before bluffing again. It takes a few iterations to build trust but it's well worth doing.

The Planning Game is just one of the twelve practices within XP. They all work to support each other. For example the existence of a coding standard enables collective ownership of the code, which in turn supports pair programming. A coding standard, collective ownership, and pair programming are three of the other XP practices. If a team used the Palnning Game without the other XP practices, they would find it increasingly difficult to deliver the new features on time. That is because the other practices work to maintain the team's relationship to the code base. In other words the parctices keep the code simple and malleable, which is vital for the developers to be able to add new features without causing bugs. You can find the other XP practices described in “Extreme Programming Explained” by Kent Beck.