How often do you find yourself prioritizing requirements with users?
Is it just near the end of your gathering efforts? Do you do it throughout on a small scale?
What techniques and tools do you use?
How often do you find yourself prioritizing requirements with users?
Is it just near the end of your gathering efforts? Do you do it throughout on a small scale?
What techniques and tools do you use?
in most cases, the users prioritize after the requirements are gathered, and sometimes it is not during a requirements gathering session at all, but at a subsequent meeting specifically around setting priorities.
i've almost exclusively used a 3-point scale. How many levels of priority do you normally have?
On one of the projects we're working on our users have told us all of the requirements have the same priority, absolutely essential. What should we do?
Well, I remember reading one book on requirements gathering and the author stated that the SRS should contain *only* essential requirements - no "nice to haves". So, it could literally be true that every requirement is essential, though I have my doubts. I have worked on requirements documents where every requirement was, indeed, essential. The users basically said, "don't release the software until you've built everything. Even if it's late, we'll wait until you're done, and won't implement into production until it's all there."Originally Posted by MJMurphy
However, this is rarely the case. I would try to get them to do relative ranking of the requirements. Within the requirement set, which requirements are more important than others - first among equals, if you will.
If that doesn't work, then I'd go to the engineers and have them prioritize based on risk, and use that to drive the effort.
I think you need to explain to them why the priority matters.
Now, if truly they need everything (which clearly I'm skeptical of) - then maybe the priority is just a piece in determining which things are built first, and therefore can be tested first. They don't have to release it yet, if just the highest priority things are built, but it does will give them more opportunity to work out the kinks in those highest priority items.
I like gescober's comments.
I'll also add a fun example from a non-software requirements prioritization effort we went through internally. We asked our sales and marketing team to prioritize the activities they were proposing we do over the next year. Now, they really don't have their "requirements gathered" all that frequently, but most of us in the company live and breathe requirements - so you can imagine how much fun we had with this.
They had a long list of activities and had narrowed it down to the top 2. But we wanted to understand what was the most important one on the list. We got a lot of push back from them in the form of "It doesn't matter which of these is more important, we are just going to do both."
But at the end of the day, we had to explain that there is only so much budget and only so many hours in the day. Therefore, we really did have to understand, if another person on the team has to choose an activity because they can only help with one of these, which one should they choose.
In the end, they were absolutely able to pick a priority - they really just had to understand why it was important to them.
Last edited by MTalbot; 05-24-2007 at 12:20 AM.
If the implementation resources aren't constrained, and all hte requirements ARE going to be implemented, then prioritization isn't really an issue. Stakeholders only take prioritization seriously when a pen is looming over a document getting ready to cross things off. It might be worthwhile to simply accept at face value that they all have the same priority until there is some pushback from IT that will force them to make choices.
This approach works for me...
I always have at least two ideas of priority in my head. My personal priorities are known as my "worry stack". This is a set of index cards I carry around with me, one of which is blank. When I'm confronted with something new to worry about, a requirement in this case, I start to make a note on the blank card, explaining that I shall start to worry about it immediately before/after the next/previous worry. Thinking aloud, I may flip through the stack muttering about how urgent or otherwise my existing worries are relative to the new worry. This gives my informant the opportunity to suggest how urgent or important the new worry is. Naturally, they will often make the mistake of talking about its importance rather than its urgency, and its project priority rather than my personal priority...
You guessed it, the second idea of priority is the project priority, of which there may be several different types, corresponding to the currently planned deliverables, one of which is usually some kind of working system. Let's assume there is only one delivery date currently contemplated (although that's not a position I favour). This delivery has a stack representing its current contents (in practice, this is usually a list). Again, I very pointedly run up and down the stack deliberating on where to insert the new item, muttering the mantra: "...so that would go...round about...here, just after [X]?". Discussion may follow.
If more than one delivery is contemplated, you have a stack of stacks. I'm quite likely to ask outright when they were hoping for delivery. Otherwise, I may just run through the dates or sequence until signs of discomfort appear...
As a result, my informants are quite likely to suggest the relative priority of each new requirement. And when the prioritization really counts, we can begin our discussions by considering adjacent requirements.
We're doing iterative development. I'm working on a project that has a 9 point scale. We see a heavy weight toward the top half of the scale and toward the top 3 priorities in the scale. This actually makes sense to me, because we have already prioritized that we are only writing requirements for the most important items, so it's hard to say any of them are low priority. But we can differentiate between the top 3 levels.
I've occasionally done priority based on allowing stakeholders to "buy" requirements. I allocate them $1000 virtual dollars to spend on the requirements, and total the spending from all the stakeholders. That gives me a ranked order of requirements priorities, rather than the traditional 3-point scale.
Posting Permissions
Reply With Quote