Take for instance this task:
Resolve issue with business stuff that's irrelevant (default materials lists were not being created w/ new programs)
The key here is the word issue. It's not defined. So you have to figure it's at least10 hours to get it defined. Then you can get actually implement what they want. Then you have to define what a default materials list is, and what they mean by default. The more people that are involved, the longer that will take. Say another 10 hours at least.
See, the easy part is writing the code. The hard part is figuring out what the heck it's supposed to do. Most project managers, and project management software think that's a task. It's not even a requirement.
Here's another one:
Final notification would be provided to someone indicating that they were something good
Here again the words final notification provide a whole world of unknowns. How will this happen? Will the user have the option to specify the method of notification? That's probably another 10-15 hours of wrangling right there. Then, another 5 hours for the actual content of the notice itself. If it's different formats, you might have another 5 hours wrangling over typography, format etc.
Another one:
Ability for roles within some department to search for people and leave notes
Roles? Which roles? Are they new roles? Search for people? By what SSN? customer ID, email? phone number? Do you know how many ways there are to find someone? Then how do you present the list? How does the user know that they have found the right person? *SIGH* Another 15-20 hours of wrangling.
Here's one more, and one of my favorites:
Business status identified and managed effectively
Manage? Manage? What does that mean? Simple Create/Read/Update/Delete functionality? Do we need a business rules engine? There's a huge difference between managing a 3 person business, and a multi-national corporation. Manage.. really... not even close to being a good requirement.
So what makes a good requirement? Anything that defines behavior. That's not something that can be defined in a single sentence. It's certainly not something that can be defined easily in MS Project, or any other project management software. It's at least a paragraph, probably more.
See not only do you have to define what you want the software to do (how it behaves) when things are good, but also when things go badly. There are usually more things that can go wrong then can go right. Each of those is it's story, it's own behavior.
Project management says you can start when you have all the tasks that need to be accomplished specified. This is just not possible. You're not done when all the tasks have been accomplished. You're done when the software behaves as the user wants.
This is where Behavior Driven Design comes in. It's not a methodology for project management. It's not a silver bullet for all your software project woes. It's a method of doing the hardest thing there is to do in any project: communicate. It focuses the attention of everyone on the project on the two single most important things in any project: Behavior, and communication.
You can find out more at: the wiki article and at the website
Posts
