Ever had a client that wanted the moon? Or maybe you were that client, greedily listing features you were going to build into your Next Big Project.

The trouble with projects that do everything and make toast too is that they never actually get done. If you're super lucky, the end result is dismal but marginally functional; otherwise, the project is destined to be mere vaporware that you can't wait to erase all traces of from your GitHub profile.

I've written before about the Quantified Task Management (QTM) standard. Maybe you've even adopted it on your issue tracker. But did you know that QTM can help save your sanity when planning a project, too?

Here are three Ground Rules to establish during your next project planning meeting, to help keep everyone's feet on the ground!

Ground Rule 1: WHAT, Not HOW

The first step in starting any project is to sit down with the client (even if that client is yourself) to discuss functional requirements.

Too often, however, the conversation drifts into implementation: "Let's use Python to deploy an AWS Lambda that will calculate the average turnaround time using data stored in Amazon Aurora..." CUT!

No matter how tech savvy everyone in the conversation may be, the functional requirement planning meeting(s) should never discuss implementation.

Selection of tools and techniques needs to be the one of the last steps in project planning, because everything that comes before informs the decision! Many projects hit the skids because the implementation is decided on before the requirements are fully understood, and the mismatch is discovered midway into development. This leads to kludgy workarounds and hacks, inefficient implementations, and wasted effort.

So, when you sit down to a requirements planning meeting, one of the first things out of your mouth as a project lead should be:

Understand, this meeting is only for defining WHAT the project does. All discussions of implementation and tools must be tabled for a later date.

And then stick to your guns.

Ground Rule 2: HOW IMPORTANT, not WHEN

One of the strengths of Quantified Task Management is in the distinction between Gravity and Priority.

Gravity is a fixed measurement of the importance of a task or requirement in the context of the project as a whole.

Priority is the urgency of the task from a development perspective.

Thus, a second boundary you should set is this:

We can define importance now to inform prioritization, but only the developers are qualified to actually determine real-time task priorities.

The only actual development timelines a client is entitled to being a part of defining are release deadlines. This is where Gravity starts to come into play:

• ALPHA: Minimum Gravity-5 complete.
• BETA: Minimum Gravity-4 complete.
• RELEASE: (Ideally) minimum Gravity-3 complete.

(More about those ratings in the next section.)

In most cases, it's safe to allow Gravity to be the client's sole control over timeline. This forces them to really consider just how much they're asking for, and when they want it by, while leaving the implementation details and timelines to the developers qualified to make those decisions.

Ground Rule 3: NEED, not WANT

I get it: requirement planning meetings are exciting, because you're exploring the unbounded horizons promised by code-yet-to-be-written. It's easy to get swept up in the fantasy: after all, who's to say it can't make waffles?

However, as project lead, it is your responsibility to bring the conversation back to earth. Requirement planning meetings are not for fantasizing, but for determining the practical needs of the project, and that requires prioritization.

This is where Quantified Task Management's Gravity metric comes in. This single 0-5 rating allows every functional requirement to be prioritized in the context of the larger project.

Just to keep things sane, you may even limit from the outset how many functional requirements can go into each "box". This will force everyone to really think about what's most important. For example:

As we define the functional requirements, we also need to determine the Gravity for each, on a scale of 0 to 5, which I'll define in a moment. Gravity-5 may only contain (five) functional requirements, and Gravity-4 and 3 only (seven) each. The rest belong in Gravity-2 and below.

Gravity-5: Critical

The project cannot exist without all of its Gravity-5 features!

However, remember: "if everything is an emergency, nothing is an emergency". A project that is purely Gravity-5 has its essential functionality, but nothing more: no polish, no bells-and-whistles, nothing to make it attractive. It's ugly and clunky, but it works.

This means that aesthetic and convenience functionality is NEVER Gravity-5!

Gravity-4: Significant

The features that are absolutely necessary for the most basic, yet attractive, version of the project are Gravity-4.

Once again, not everything can be Gravity-4. This should be limited to only those functional requirements which directly improve on the essential (Gravity-5) functionality. No bells-and-whistles here.

Using a Gravity-4 project should actually be a pleasant experience, but it is still only augmenting the Gravity-5 functionality. Only the most important aesthetic and convenience functionality here!

Gravity-3: Major

Now we're into non-essential territory. Gravity-3 can contain all that additional functionality and polish that really should be added if time permits.

This may seem somewhat brutal, shoving all the good stuff into a "may not happen" bin, but one should always remember that the first goal of software development is to create something that works. If you're building a chat app that cannot allow you to chat (Gravity-5), but happens to have the "extra feature" of allowing social media cross-posting (Gravity-3), haven't you just built a cross-posting app?

Don't misunderstand, though: Gravity-3 is still important. These are all those functional requirements that the final release really should contain, assuming nothing goes haywire when implementing the Gravity-5 and Gravity-4 features.

However, if the project goes off the rails, Gravity-3 tasks will be sacrificed out of the first release rather than leaving out Gravity-5 or Gravity-4. (Gravity-2 and below don't even factor into the first version!)

A Gravity-3-complete project is basically production-quality software. It looks nice, responds nicely to the user, and has that dash of extra "WOW" that sets it apart from similar project.

However, only the most important "bells-and-whistles" should be here; the "gongs" should get left out at this level! Off-the-wall nice-to-haves (like making waffles) is still outside of the scope of Gravity-3.

Gravity-2: Minor

Here's the rest of your bells-and-whistles, everything that would make the project really shine, but which has relatively little to do with the core functionality. This is when you can start having fun with the requirements planning...so long as you don't go too nuts.

A good way of viewing Gravity-2 is as your "Essential 2.0 Features". These are features which almost certainly won't make it into the first release (although it isn't impossible that a few might slip in anyway). If you manage to ship a Gravity-3 complete 1.0, then these will be promoted to Gravity-5 and Gravity-4 for the next major release.

A word of warning: The gongs still don't belong here! For that, we have to move down a notch...

Gravity-1: Trivial

This is the pool for selecting Gravity-3 tasks for subsequent releases (2.0 and on). Also, here be gongs.

There's only one rule here: these are things that you are reasonably certain could belong in the project at some point. If you can't imagine the feature ever being worthy of promotion to Gravity-3 or above for a subsequent release, it doesn't belong here.

Gravity-0: Wishlist

This is the catch-all for anything that was assessed and found unworthy of the other five Gravity ratings. You can think of Gravity-0 as the "perfect world future version" of your project; if everything goes according to plan over the next few cycles, these are things you want to add.

In other words, all your waffle-making extras belong here!

Yet, even here, there is one rule: These are all features that have been discussed in some fashion! That nutty, unassessed "what if" idea you wrote down at 2 AM doesn't belong here, for one simple reason: it's unassessed.

There's actually an interesting reason for that: you don't want tasks that should have a higher Gravity rating landing here and getting lost! This is the scrap bin; seldom sorted, and usually only combed through when you're looking for something weird. A realist wouldn't expect the majority of Gravity-0 tasks to ever see the light of day again, not because the rating is inherently terrible, but because of human psychology: "out of sight, out of mind".

So, if a task hasn't been properly assessed, it has a special place of its own...

Triage Gravity

After your functional requirements meetings are over, everyone will still have ideas for features: you, the client, other developers, random users. If we're honest, most of these are probably going to wind up in Gravity-0, but there are always gems worthy of a higher rating...maybe even an overlooked Gravity-5!

Thus, if any feature or functional requirement has not yet been properly assessed, mark it as Triage Gravity! This ensures it can be properly revisited later, given the attention it's due, and then assigned the proper Gravity rating.

You can also use this label for anything that is tabled to be discussed later.

What Now?

So you now have your list of functional requirements or features, each one with its Gravity rating. Now what?

This is the list you bring to your developers, to figure out the rest. Think of this part as the Four Ts. Understand, the order isn't essential here; decisions in one area can affect the others.

Tasks

Break down each functional requirement into its major tasks. Most of these tasks will inherit the Gravity of the functional requirement, although there will often be some that need a lower rating.

Once you've broken a functional requirement down into tasks, you may choose to assign Gravity-Σ (Gravity-Sum) to the requirement itself; that is, its Gravity is now the SUM of its subtasks.

Tools

You can begin discussing the best tools and techniques for the job, although this is usually best left until you at least have your Tasks figured out.

This is also where the QTM metric of Friction comes in: the measurement of how many resources are available to help complete the tasks. What documentation exists for the tools? What precedence is there in doing this with the chosen technology?

Timeline

Set Priorities, and come up with your schedule: sprints, release deadlines, all that good stuff. Remember, Gravity is fixed, but Priority can change!

While you're doing this, be sure to estimate the fourth QTM metric: Relativity, which is how uncertain you are of your time/complexity estimates. (By the way, Relativity-5 means "Black Hole"; an uncompletable task.)

Teams

Once you know what you're doing and when you're doing it, you can begin dividing up tasks among the developers. All four QTM metrics are really helpful here, in ensuring an even spread across teams:

• Evenly distributed Priority means no one is waiting on anyone else.

• Evenly distributed Gravity means everyone is working on something useful to the project.

• Evenly distributed (or at least scaled) Friction means no one team is getting stuck with The Hard Stuff.

• Evenly distributed Relativity helps prevent one team from getting bogged down.

---

You can learn more about the metrics of Gravity, Priority, Friction, and Relativity by reading the Quantified Task Management (QTM) standard.

Go forth, and define your features with confidence!

---

More Reading...