Your ability to deliver a web/software project successfully is largely dependent on how well you manage that project’s requirements. I’ve been repeatedly schooled on the how and why of great requirements management as I’ve watched so many good projects turn into nightmares. Being taken down with the ship is about as fun as it sounds, but if the things that I’ve learned can help you steer clear of the icebergs, I’d be happy to share. Let’s go to school.
The bell rings:
Let’s frame the discussion; A client hires you to build a web application, they bring a wish list of things they want it to do, and they ask you how much it’s going to cost. The more you know about what’s required, the more accurate your estimates will be, so you begin to size up the scope of the work by putting the project’s requirements down in writing. You can gather and store those requirements in a ticketing system like Lighthouse or Jira, but you can be similarly effective using Post-it notes and a smooth wall. Let’s bracket out the discussion about tooling, assume that we’re going to use the term “ticket” to describe a distilled requirement, and take a look at the component parts that make up a requirement:
- Ticket title
- Ticket description
- Ticket milestone
1 – Ticket title
The title of a ticket should strike to the very heart of the requirement, summarizing it succinctly and unequivocally. As is true of great ticket content, a great ticket title should be:
- Testable – you’ve made an assertion about what outcome you desire
- Contextual – you’ve described the conditions and nature of the players involved
- Granular – you can’t break this requirement into smaller requirements
The pro requirement gatherers that I’ve come to know develop formulas for their ticket titles, and stick to them. If this was your formula:
{persona} should {imperative} when {condition}…you might expect to see the following ticket titles:
The system should present visitors with a newsletter subscription form when the signup link is clicked The system should present an error message when a visitor submits a subscription form with errors A visitor should be added to the mailing list upon signing up for the newsletter A visitor should be presented with a confirmation message upon signing up for the newsletter The system should send monthly subscription reminders to those on the mailing list An administrator should be able to send a plain text email to mailing list subscribers An administrator should be able to send an HTML email to mailing list subscribers The system should remove a subscriber from the mailing list when their emails are found to bounce A subscriber should be removed from the mailing list when they click the “unsubscribe” link A subscriber should be presented with a confirmation that they've been unsubscribed when they click the “unsubscribe” link
Things to notice:
- Each ticket title describes a discrete user/system interaction. Note the splitting of plain text and HTML emails into two separate tickets. From a systems perspective, they may involve two very different pieces of code and, as such, constitute two requirements.
- The development/design activity represented by each ticket can be tested for completeness by title alone, by asking the question “did the {persona} {imperative} when {condition}?”
- As I wrote the ticket titles, a set of personas emerged; they are: “the system,” “a visitor,” “a subscriber,” and “an administrator.” Like good characters in a book, these personas will develop as the story unfolds, and should follow you around for the entire duration of the project.
If your instincts told you to bundle all of those tickets into one ticket called “Newsletter,” you may have a medical condition called “epiccitis” – a propensity to write Epic Stories. Epics are a great way to bury complexity where it can’t be seen, leading to underestimation, and ensuring that your projects will run over time and blow your budgets. Write Epic fiction, not Epic Requirements.
2 – Ticket description
If your ticket description is half as good as your title, you’re still well on your way. Let’s extend the system that we used to write our titles, and write example ticket content for the ticket titled “The system should present visitors with a newsletter subscription form when the signup link is clicked.”
TICKET TITLE: The system should present visitors with a newsletter subscription form when the signup link is clicked TICKET DESCRIPTION: Upon clicking on the “subscribe now” button, a user should be required to supply the following information: * Name * Email (validate against RFC 2822) * Acceptance of privacy policy …and may optionally provide: * Occupation * Telephone number
Now there’s a requirement that designers and developers alike can sink their teeth into, right away!
3 – Ticket milestone
I’ll tell you how I feel about this, then you can develop a system that works for you.
Milestones should occur regularly, like a heartbeat. For simple projects, set a milestone every week. For complicated ones, three or four weeks.
Milestones should never move; the only thing that should move are requirements – in and out of milestones. When surprises come up, write the surprises down as new requirements (new tickets) and do one of three things:
- Schedule the new requirements in a future milestone
- Move requirements out of the current milestone and into a future milestone, to make room for the new ones
- Add the new requirements to the current milestone and assign additional personnel to that milestone; the more people working on a milestone, the more requirements it can hold
When a milestone is reached, a snapshot of the project should be deployed, unfinished tickets (tsk, tsk) should be carried forward, and beer should be un-fridged.
Therefore, good milestone names:
Iteration 1 Iteration 2 Iteration 3 (Internal Launch) Iteration 4 Iteration 5 (Public Launch) Iteration 6
Bad milestone names:
After Friday Whenever you get time Yesterday
School’s out
If writing requirements in this way seems overly complicated and time-consuming, there’s good news: you can reuse them. The first time you write a series of stories for “new user registration” it will seem like time is standing still, yes, but if you write them in an abstract way, you should be able to drop them into all subsequent projects that require “new user registrations” and customize them from there.
Oh… I almost forgot; here are the answers to the test:
great requirements = testable requirements = clarity = accurate estimates = less rework = more met deadlines = happier clients = happier staff = ??? = profit!
So next time you sit down to write a ticket, if you can’t think of a good title, chances are you don’t really know what’s required. And, as we’ve learned from G.I. JOE, knowing is half the battle.
Tags: tutorials
