What Are Good Requirements?
What makes a good requirement?
That’s something that is completely open to interpretation. In my humble opinion, a good requirement is one that is clear and direct. It communicates what it is supposed to and then moves on.
No muss, no fuss.
There are many out there that will disagree with me on this. That’s OK - it’s all open to interpretation and what you’ve seen work before, or have tried, have succeeded with, have failed at, etc…
See to me, in the scenarios where development is not run by product (which should be every scenario if you want to do things right) you need to have a good partnership there. If that doesn’t exist, things will go down the tubes pretty quickly. That being said, you don’t have to love each other and hold hands - but something has to be shipped.
Now, to boil this down pretty quickly, I really see there being only two types of requirements:
1. Agile requirements; and
2. Waterfall requirements
These are really polar opposites of one another. You can’t get much different, aside from the fact that you are communicating the same problem you want solved within each - they are both just different ways to communicate them.
The thing I have come to realize is that for agile to work - for it to really work - you need everyone behind it and you need pretty smart developers who are on the ball. The main reason for this is that you want great code to be written, but the time you are saving by not writing long (and I mean looong) requirements documents produces ambiguity, and that must be filled in by the developer as they go.
They must ask questions. They must talk to you (the product wonk). And above all, you must trust each other.
Some developers have serious issues working this way - I get it. I understand it’s not easy. It puts a lot of onus on those that are writing the code, as opposed to the waterfall way….
Now in waterfall, at least in my experience, you are pushing away communication in favor of documentation. Developers want every single piece of a feature mocked-up, written down, and worked out before they even start thinking about the code. I always picture this style of process as taking things and lobbing them over walls. Requirements over a wall to dev, code over a wall to QA, QA over a wall to production, etc, etc…
Especially if your team is small, working this way is not leveraging one of the team’s crucial strengths - it’s size.
A lot of companies work in waterfall, and it does have its place. Specifically in organizations that demand a heavy process workflow through a release - or something that has a ton of formal check points. Two examples here (respectively) could be a bank and a consultancy
If you are going gangbusters trying to get products out the door, the last thing you need are formal check points. The last thing you need are 50-100+ page requirements documents. But that is what happens. This gums up the works for several key reasons.
The main one is, people stop talking. They stop asking questions. They just assume they can blindly follow the documentation - and if it doesn’t turn out right, oh well - wasn’t documented that way, so it’s becomes a bug. People way smarter than me came up with the agile manifesto for a reason. It can and does work.
People are smarter than this and everyone should expect them to be.
Of course developers need things to go on. You can’t expect them to read your mind and they can’t design anything (in most cases). But they are smart. After all, they are computer programmers.
The bottom line is this - no one can tell the future. As features get implemented, they change. Sure you know a lot of things up-front (button goes here, text goes there, save this, etc…) but you are 100% bound to miss things. If your product release process doesn’t account for things being missed down stream, it’s wrong.
Remember one of the key tenets of agile - put things off as long as possible until the last possible moment you can decide to ensure you have the best set of information at hand to make that decision.
Those things don’t happen in closed-door offices with a product manager huddled over his keyboard typing out requirements and acceptance criteria fast and furious. They happen in talking to those coding out those ideas and breathing life in to them.
But, not all teams are cut out for that sort of challenge. And that’s OK too - just make sure your management team knows you are going to need a solid chunk of time (1 1/2-2 months) per release cycle. And make sure you have some spare toner and paper ready for your printer. You’re going to be doing a lot of editing on those requirements docs.
Maintain Your Focus
Here’s a great little bit from Manage It, by Johanna Rothman…this book is highly enlightening and it’s great to know I’m not the only person thinking some of these things.
I once worked for a company that decided aftear a several-day offsite strategy meeting that we were going to “focus on five.”
That isn’t focus.
Focus means to center all of the attention toward something. Five strategic areas are four too many.
Unfortunately, it’s all too common for companies to spread themselves too thin in order to be all things to all possible customers. If that’s the problem where you work, move to short iterations as quickly as possible so you can say to your management, “OK, we can start that next week, because we’ll be finishing this in two days.” Even better, make sure your iterations start and end in the middle of the week, such as a Wednesday. That way if your managers have “a-ha” ideas over the weekend, they’ll probably give you a couple of days to finish what you were doing.
Your team will thank you for maintaining focus.
Stay the course, folks.
If that course includes too much stuff, either strip some of the dead weight, or move on.
Product Release Plan
There is a great book called Manage It!, by Johanna Rothman. She does not disappoint, and really gets into the nitty gritty details about managing projects. While this is billed as a “project management” effort, it really does apply to product managers a great deal.
One of the things Johanna discusses early on is some of the tools she uses to define her projects - a project charter and a project release plan. While I believe both of these are valuable, I couldn’t stop hearing the “it’s just too much documentation” argument in my head. Would people refer to the charter for details, or the release plan? While I understand the difference on the majority of counts, I wouldn’t expect everyone to - even in the smallest of organizations.
So, I took what Johanna has detailed out as her two templates (the charter and release plan) and created a Product Release Plan template. Hopefully, this would become part of your PRD, and be refined as necessary for each release. There are some critical elements that are called out in the book that I have included, and they are pretty clear why.
That all being said, here is the template:
- Release Theme
- Release Requirements
- Release Criteria
- Release Goals
- Schedule Overview
- Risks
I’ll cover each of these points separately with a brief overview.
Release Theme
This should match to the release detailed on your roadmap. As I discussed in a previous post, creating theme-based roadmaps has a big advantage, and delivers a lot of clarity about a release without getting into “feature this” and “feature that” and scheduling.
Release Requirements
In her book, Johanna points out that each project should ideally have 1 driver, 2 constraints and 3 floats. The “driver” is what the project is absolutely dependent on - it’s the most critical thing. For example, it could be the release date, or the feature set, or a low number of defects.
A constraint is the second most important thing. The project isn’t 100% dependent on it, but it’s still pretty damn important. Floats are those items that you have more flexibility in managing. IE, stakeholders aren’t going to lose sleep if they aren’t delivered.
Release Criteria
These are the things that will mean the release is ready to ship. For example, is there a certain number of SEV-1 defects that need to be resolved? What about hitting a certain timeline? Maybe a specific set of features need to be met? Those points are all factored in there.
Release Goals
Goals are not requirements - they are items that would be ideally completed along with the release. For example, “making the performance of feature A 10x better than what the requirement states” or “adding a brand new set of smoke tests into the automated testing process of the product.”
These goals could be broken down into specific sections, such as product goals, team goals, project goals, and organizational goals. I’d stay away from trying to be too detailed here - especially on your first pass through a document such as this. It’s more important to get the key things down up front and make sure the team is executing and delivering on requirements first.
Schedule Overview
One of the methods Johanna states in her book for scheduling is called “top-down.” I prefer this method to all others, since it involves setting milestones first, and working out the details for each milestone from there. This is much more conducive to successfully planning releases from a roadmap, since the roadmap itself is a high-level set of milestones.
Jot down the milestone name and the estimated date for its completion in this section.
Risks
Risks can be difficult to identify clearly. However, they are very important to have and be aware of throughout development to ensure the proper mitigation actions can be taken. Within this section, identify each risk, the probability of it occurring, its severity if it did occur, the date at which you are most at risk for it causing problems, and the action being taken to resolve it.
I believe that most of these will be identified by the development team. However, because a product is much more than just code, if there is a marketing risk it should be identified here as well. For example, “a relationship with a PR firm may not be in place in time to get the press release done and out prior to the ship date.”
Breaking into a Sprint
I just stepped through a session planning out the next couple of iterations on a product halo with a colleague of mine. The process we have taken to using is quite cool. I don’t proclaim it to be unique in any sense of the word, but definitely something I’m liking the feel of, and one I could see really developing and growing with the organization.
I started by writing out a set of bullet points, broken in to feature groups on the white board. This was our baseline. We talked through each point, made some revisions, removed some, added some others, and proceeded forward. This really allowed us to reset, and get in to what it was we were trying to accomplish.
We then proceeded to prioritize each bullet point. Since we have a lack of customer data, and some things are just obvious (especially when dealing with halo items), it was pretty easy to go through and assign low / med / high or 1 / 2 / 3 to each bullet we had written up there.
After the bullets were all prioritized, we then assigned gross hourly estimates to them - nothing under 2 hours allowed. Since the bullets weren’t full requirements, this kept things padded to a reasonable amount, allowing us to continue marching towards to goal (yes, details on what exactly what is forthcoming).
We then decided, right or wrong, that since these are halo items and not product “features” in the true definition of the word, we didn’t need to rev the version number at all, really. So it was just a matter of adding up all the gross estimates and then identifying sprint length and doing some simple division.
So, we landed on each sprint being 10 days in length for the project. With all the tasks grossly estimated, this ended up being something like 9 sprints total. We backlogged a few things, but couldn’t really get that gross-level estimate to budget too far, so we stuck with it.
My colleague now has the lucky job of fleshing out those bullets in VersionOne and assigning them to the correct sprints. And then of course, gathering up all of the materials that do already exist and attaching them to the right items, and then proceeding to execute on some key market research tasks that were identified.
Yeah, I guess I’ll help out at some point.
So, what did we end-up with? Well, a pretty common thing - a set of requirements, associated to a release project and sprints in our requirements / product management tool (VersionOne). “Big deal” you say? Well, it’s important to recognize that when you have a crap load of things to do (especially halo items, which can be convoluted), using a framework / brief / flexible process that helps get all that stuff that’s currently up in your head down on paper and in front of others, can be a huge weight off your shoulders.
Keep tweaking, keeping writing things down - but when you find you have it all up in your head, take a step back, get some people in the same room as you and start to write out bullet points and take it from there. Worst case you end-up with an empty head and an eased mind. Best case, you have developed a quick and dirty roadmap for the next several weeks that can be iterated on.
Some Agile Development Commentary
I’ve written several posts in the past regarding agile development and how we’re leveraging some of it’s benefits internally at the present time. There is a solid post up at Tyner Blain, in which Scott provides some good feedback on a post written by fellow blogger Mishkin Berteig.
There’s a story a friend of mine (who works within a very large organization as a project manager) shared with me a while back. He was sitting in a meeting with a client and his top project team. A piece of QA within the release process for their code had broken down their process, preventing them from essentially, getting shit done.
That’s generally bad.
My good friend recognized something very critical though - why was backend regression testing (the piece of QA in question) occurring for the UX component of the software? They had nothing to do with one another, but were on the schedule and continued to be done.
The response from those around the table was basically, “that’s just how we do things.” Yikes! That answer, right there, can sum up a lot of what’s wrong within long, severely drawn-out release cycles.
We’re trying to get a v1.0 out the door, and will probably end up doing so this week. Now, we’ve been working on this (from the ground up) for the last, say, 2 1/2 months. That’s an incredibly short period of time to a) define a product b) get it through a development cycle c) market it, and d) release it. If, at any time, my response to a question had been, “that’s just the way it’s done” and thus prevented us from completing a key piece of the PDLC faster, I’d have expected I’d be fired partway through the process.
These types of excuses can be directly tied back to a few things:
- Egos - people want to cover their own asses
- Straight-up stupidity and fear - people don’t understand their role / job and are afraid to say, “I don’t know”
- Fear imposed by higher-ups - VPs and directors with no clue and way too much leeway to say, “my way or the high way”
- Silo’d, non product-centric organizations - those that define the company around roles instead of products
That last one is very important and one I remember touching on before. Agility isn’t just about having senior-level developers you can trust with flexible requirements, but it’s about everyone caring and contributing to the products themselves.
Who cares if someone is “in marketing” or “in legal?” Why does that matter? Their sole function is to solve pain for your customers and build great product. That’s why it’s so critical to commit to product management and not make it a half-assed effort just because everyone else is doing it. Get them in the center to do what they do - ensure the planning is place and crap makes sense, and then execute.
I digressed quite a bit, and it’s got nothing to do with how Scott’s post is written. The difference between using waterfall and using agile approaches is very simple - at least in my mind. If you have a complex, workflow-intensive product (like a banking or insurance-level application), you should be planning your PDLC’s using waterfall methods. If not, plan your whole PDLC using agile. No question.
Of course, that’s not to say, product groups within the overall (probably silo’d) organization that make up the individual feature teams or “product” teams if your suite is broken down that way (a la Microsoft) can’t use agile. They should. It would probably help them work faster and more closely together.
Sorry, Scott — I started out by intending to respond to some of your key points, but kinda got off on a tangent.
