Goals and requirements drive the work schedules of all projects. Some of these requests are necessary to the success of the current project, others are not so critical. Yet sometimes we lose sight of this and spend many work hours trying to complete more than what can be done within the timeframe of a project. In this column, Johanna Rothman reminds us to look critically at what we're working on to make sure we're satisfying the goals after the requirements have been satisfied.
Kris, a technical lead, saw Tom, one of her project's developers running down the hall. She was curious, but didn't interfere. A few hours later, she saw him running back. He stopped and made a U-turn into her cube.
"Kris, do you have a minute?" he asked.
"Sure, what's up?" she said.
"Well, Danny over in marketing wants me to add these things to the screen, and I was wondering if you could take a look at it?"
Kris started reviewing the changes and asked, "Tom, is this why you've been running around all day?"
"Uh, yeah. Why?"
"Because what Danny wants is something that's a goal, not a requirement for release. Remember the product roadmap? This feature is for the next release but was a goal for this release. We need to finish the requirements before we think about the goals. Let's go talk to the project manager and see if anything's changed."
Many projects have more requirements than can be finished in the desired project time. Some of those unfinished requirements turn into goals. Other times, the project team members have internal goals it wants to accomplish. Or marketing has said it would be nice if the team could achieve a certain performance or reliability greater than what it specified. Or the organization wants faster projects. All of these are goals, and the team should satisfy the goals after it satisfies the requirements.
Separate Goals from Requirements
It's easy, especially at the beginning of a project, for a project team and the people who request deliverables (some of which are requirements) to be unable to differentiate between goals and requirements. The project team might be excited about the project and want to do everything. The people who want the release might feel as if there's pressure for everything in this release. But it's too easy for the project team members to be sidetracked if they haven't differentiated between goals and requirements.
Here's how I do it. First, take your requirements (if you have them). Now, for each requirement, ask the person who gave you this requirement into which bucket this item belongs. The buckets are:
- Product requirements required for this release
- Product requirements for some time in the future
- Project goals, such as a reliability or performance measurement that exceeds the product requirement
- Team goals—things the team would like to do (e.g., pay down some technical debt by investing in more unit tests)
- Organization goals, such as finishing this project before the next one needs to start
Only the first item in this list represents the project's requirements. Everything else is a goal.Define Release Criteria
Now that you know the requirements, you can test whether or not you've bucketed everything correctly by defining release criteria. The release criteria should be a subset of the requirements. If you find anything creeping in from the goals, you know you either have more requirements than you thought or your release criteria are not actual release criteria—they're goals someone wants you to deliver.
Here's how this could play out in a project. Imagine you have an online store, and you have a requirement of improving the search for a specific set of items—say, canary cages—by ten percent to bring total search time for canary cages to less than two seconds. In addition, you know that for next quarter's release, you need to bring canary cage search to less than one second—as well as bring the search for all cages to less than 1.5 seconds. This is a goal for this release, but a requirement for next release. If you can see how to fulfill that requirement now for no more money and time than you're already spending, fine. But if you can't, you only work on canary cage search.
In addition, the team members realize they've incurred some technical debt by missing some unit tests, and they don't have all the performance tests they want for all cage searches. They do have performance tests for canary cages.
As a project manager, I would talk to the team and ask where the unit tests are missing. If team members were going to work in those areas of the code, I might ask them to timebox any additional unit test development—i.e., make sure that the team members develop unit tests for the code they're developing (only for code they're touching) and to timebox the time they spend doing that. We would agree on how much time to spend fulfilling the requirements for release because the time the team members spend developing tests for already-running code is time they're not spending on finishing the features for this release.
This conversation tends to be tricky. I don't want to prevent people from providing more information about the code base, and I don't want people to wander all over the code adding unit tests. I tell them that and ask them to monitor their time and let me know if adding more unit tests is taking more time than they thought. An organizational goal for this release might be to meet the quarterly deadline for the release.
Case in Point
One organization I previously worked with only had eighteen-month releases. They wanted to transition to quarterly releases but suspected that they first needed to transition. They thought moving from an eighteen-month release to a three-month release might be too difficult for them. So, they cut the goal in half as a requirement. For the first project, the requirement was nine months from start to release, with a goal of three months to finish the project. The project took twelve months to complete. At the retrospective, the team members discussed what they could do differently during the next project and planned for a six-month duration. They met that six-month requirement and learned what they needed to do for a three-month cycle. Having the original goal helped them learn what they needed to do, even though they couldn't meet the goal.
Summary
Once Tom realized what he was doing—working on a goal instead of a requirement, he asked Kris for help in discussing the issue with Danny. Danny thought the team should change what they were doing to accommodate his request to move the feature from goal to requirement for this release, so they checked with the project manager. The project manager explained to Danny that it was too late in this release to change the requirements, but she would be happy to discuss reordering his requirements in the future.
Your conversations might require more people to make a decision about whether this feature is a goal or requirement, but having the conversation will help everyone do what they need to for the current project. Remember, project requirements and goals are different, and you should treat them differently. Spend your time on the requirements, and then attend to the goals.
