Mike Diehl's WebLog

We're starting a small project for a new client, and of course, we're gathering the requirements for their solution before we dive into designing and developing it.

Of course, clients start off with a grand vision of what their new software will be able to do for them, and then they say they want all that for a limited budget, and can we have it done next week?  The overlying principle in any project is that there are really three main constraints: time, money, and quality. The scope of the project must fit into the triangle formed by those three constraints.

So, Joel got us started a couple of years ago on a great way to help clients identify the priorities for the requirements they have given us. When we arrive at a list of requirements, we then assess them in four areas:

• Benefit - the relative benefit of having this feature or requirement in the final solution
• Penalty - the relative penalty of not having this feature in the final solution
• Cost (or complexity)  - the relative cost of implementing this feature
• Risk - how much you don't know about implementing the feature

We use a spreadsheet, and assign values 1 to 9 for each of these columns, next to the requirement itself. A benefit of 9 means that it is high benefit to include this feature, a penalty of 9 means that it would be really bad if we didn't include this feature, a cost of 9 meant it would be really complex or time-consuming to implement this feature, and a risk of 9 meant we didn't know how well the feature could be implemented.

To come up with a ranking of each feature, we use a Priority column which simply totals up each of the four B, P, C, and R factors, and then we sort descending on the priority column (this works great in Sharepoint too). Sometimes we will weight the factors by multiplying each of the factors by a percentage (35% B, 35% P, 15% C, 15% R) but it usually works out about the same.

Now we have a list of features/requirements that have the most important ones at the top, the least important at the bottom (note that you may have to account for dependencies between requirements as well as the priority). We can apply "scope" to the list and cut off the bottom stuff according to the amount of time or budget we have (assuming you don't want to cut quality).

It works pretty nicely.

I recently used it at a company where we were involved in a SEPI project (Software Engineering Process Improvement) and they found it a really useful exercise. I was able to develop an iteration plan for the construction phase based on implementing the features in the priority order. The early iterations were the hardest, most time-consuming ones, and, frankly, some parts of some of the early features spilled into the next iteration. But our last two iterations had the trivial stuff scheduled in it, so we were able to make up the slack easily. We also had early releases of the most critical pieces, and were able to adapt to some of the changes that were identified by the early adopters. If we had scheduled it otherwise, we would not have made the deadline. We did end up dropping some of the lowest priority features, but no one cared - success criteria were based on the highest priority features, not the lowest "nice to haves".

There's a new feature in Visual Studio 2005 Team System (VSTS) in the source code control area that I really like.

First of all, let me say that source code control has been considerably revamped in Visual Studio 2005 - there is a new edition of Visual Source Safe, which does not require Team System, but which has been updated to be more reliable, especially over slow links. However, there are a lot of new features in VSTS Source Code control that should really make you consider using VSTS, especially for teams of 5 developers or more, but even for smaller teams. (Even a one-person team should be using some kind of source code control.)

Secondly, let me briefly talk about "The Zone". Joel On Software talks about it, many others do too, but suffice to say that "The Zone" is a place where developers find themselves very focussed and productive. Somehow I think many developers find it as easy to be procrastinators and time-wasters, it's something in our makeup. Good developers are often seen as lazy - writing the same thing twice is too much work, let's factor it out instead.

But I digress. When team members are in "The Zone" it is best to leave them there. It is easy to be distracted and suddenly the zone is gone (some have termed it "the bubble" and it bursts). Anyway, real progress happens when you are in the zone.

However, it is also important in projects to fix defects as early in the process as you can (excepting on a number of other factors that might prioritize them to later activities). Defects are often found during testing activities, and, in ideal circumstances, by someone else other than the developer. Fixing defects often means that a developer has to go back to what they had previously worked on and diagnose and fix the defect. (All those developers whose code has never had a defect need not read any further.)

Going back usually implies breaking the zone. And what if you had started work on a really cool new feature and needed to make sure your new code wasn't lost?

Answer: you put your new work on the shelf. Almost literally. The new source code system in VSTS allows you to "shelve" your changes into the SCC repository, go back to the old code, fix your changes, and eventually get back to the cool stuff - you fetch back the cool code from the shelf. Bam! Back in the zone.

Shelving has a number of other uses as well - transferring new but incomplete work to someone else, doing a "spike" on a new feature, heck, even just ensuring that all developer work is backed up (so you don't have to worry about not backing up the dev workstations).

Joel has some good things to say about CMMI, in relation to Visual Studio Team System (VSTS).

I admit I have fallen into the trap of saying that using the CMMI process template in VSTS should be reserved for large organizations that are highly regulated and have money to burn, like governments, or agencies like NASA.

I will have to think and read more about this before talking about CMMI in another VSTS class. While I suspect that an organization adopting a more formalized SDLC using VSTS should not start with the CMMI process template, it is possibly something they should strive for as they grow more accustomed to a repeatable, improving process for software development.