What Are You Working On?

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.