Rank Requirements

 

One of the questions I ask project teams is how they know what to do when. Most of the time, the developers look at me as if I’ve grown two heads and say, “Well, we look at the requirements. We do the high ones first, the medium ones next, and the low ones if we have a chance.” I then ask the next question, “Do you ever find that some of you implement different high requirements in a different order?”

If you have a system with multiple components to the architecture, such as a front-end, middleware, and a back-end, chances are good the developers are separated into functional teams of front, middle, and back. And, unless the teams talk to each other continuously, the teams will each approach the requirements in a different way, not a coherent effort. What that means is that the UI for data entry is complete, but the middleware isn’t done or the back end database work isn’t complete. Or the watchdog time is done to kick off events, but the event code isn’t complete. When pieces of a product are done, without making sure the entire feature is designed and written from end-to-end, problems ensue:

  • The testers can’t test, because they can’t test one piece of the feature without the others in place. Even if you have testers who can write code, they can only perform unit testing, or perhaps module integration testing, not system-level testing.
  • The probability of not-enough features being complete at release time is high, higher than I like.
  • If you’re dealing with a long defect list, sometimes developers will fix defects they perceive to be easier to fix, rather than ones the customers need first (even if they’re taking defects in priority/severity order).

One of my clients complained about ranking, “We’ll have hundreds of requirements. It’s overwhelming.” If you’re still doing big releases, ranking requirements helps you create smaller releases. (Take the first 10 requirements and make that a smaller release. You don’t have to release to the external world, you can release to the test group.) You don’t have to have iterations if that bothers you. You can use staged delivery as a lifecycle. But people can’t deal with hundreds of things on their to-do lists. It’s too easy to not have a sense of urgency about the task list if it’s hundreds of tasks long. But if you rank requirements, you can then rank tasks. You can use rolling wave scheduling to schedule just the next month’s worth of deliverables, and now everyone has a manageable task list. The PM can work with people to make sure they’re keeping a steady pace, and if someone can’t complete their work when they thought they could, the PM can see the impact of that easily.

If you don’t rank the requirements, the developers will do so when they implement the requirements. I’d rather the project team make a conscious choice about when to implement which feature. Conscious choices lead me to better planning and monitoring of projects I manage.

Leave a Reply