I have learned an important lesson from my combined experiences at all the places I’ve worked. That is: raw requirements cause waste. A term I’ve used (and have heard others use) is that requirements are either “baked” or “not baked”. For a development team to plan an iteration, or a scope of delivery, the requirements need to be baked. If we pull the development team into a planning session, we ensure the requirements are fully baked before the meeting. Developers will be asking specific questions about the details of the requirements, and answers need to be readily available.
A big cause of waste is when a project manager inaccurately declares the requirements as actionable and the entire team meets. This is the most expensive meeting you can have. As soon as the developers ask questions, a discussion ensues among business stakeholders on what the requirements should be. At this point, the developers sit and listen until the stakeholders finish defining what the system should do.
The above is a strong indicator that the requirements aren’t baked. There are holes in the analysis, and it comes out as soon as a developer asks a question about the expected behavior.
TIP: Project Managers: ensure the requirements are fully baked BEFORE you take up the ENTIRE team’s time. You may need help from the architect or tester, but ensure the center is not raw when the whole team is pulled in.
UPDATE: ScottBellware was a bit confused about the context of this post (see comment below), so I thought others might be also. This post is about behavioral requirements for a single user story. Very small scope. Before the team can estimate, this story must be “baked”. Otherwise, the coding is guesswork.
@ScottBellware,
I love that article by Jeff Patton, and I don’t believe I’ve written anything that contradicts it other than use the word “requirement”. By that, I’m talking about user stories and the details that define the scope of the user story. The requirements for a particular user story.
To help clarify the context for you, the first story on the product backlog engendered a 30 minute conversation amoung business stakeholders while everyone else sat and listened. Often this listening is good. In this case, it was evidence that the requirements for this user story were not baked at all, and there was no way the team could estimate it until many more behavioral decisions had been made. We pulled the story until we could define it better.
Thanks for the comment.
@James,
I would agree with you.
Jeff Patton does a much better job than me in talking about why “baking requirements” is often an anti-pattern:
http://www.agileproductdesign.com/blog/requirements_considered_harmful.html
Since what you’re saying here has been increasingly challenged over the past half-decade by folks who don’t submit themselves to this kind of project ceremony, it’d be valuable to understand more about the project context that your propositions here come from, and the context wherein you believe they’re applicable.
I can see this kind of stuff as valuable in traditional phased development, but I think it would be a detractor for contemporary cross-functional teams and practices.
One thing to make sure is that business rules are not confused with requirements. Developers can make progress on the system while rules are being defined as long as they externalize those rules and engage the business in managing them.
JT
This is a GREAT point.
This is one main reason why I left my last job. Of course it’s the developers fault for not getting it done in time.
The ingredients of a pushover and indecisive PM mixed with a demanding client with just a touch of haughtiness is like putting exlax in the brownies. In either case, there will be crap to deal with.