Objectives represent non-requirement activities that must be done to enable successful delivery.
Objectives can be used to represent overhead, setup and team improvement activities on a backlog. These concerns should not be considered as user stories as they add no direct value to a consumer. Objectives, therefore, should not contribute story points to team velocity (for agile/iterative teams) as they are not part of the product scope and will be inconsistent in terms of effort, therefore extrapolation of their completion is meaningless. Instead Objectives are best thought of as overhead. Explicit representation of overhead vs. requirements means that teams can be transparent in discussions with Product Customers regarding the necessity of overhead activities and trade them in/out against requirements.
Typical Objectives that software development teams might need include:
- Setup development environments
- Setup Continuous Integration Environments
- Acquire Test Environments
- Risk mitigation activities (don’t put risks on a backlog, as the mitigation might not work!)
- Run Team Forming sessions
- Running team retrospectives
The split between requirements and objectives on a backlog can be actively managed to monitor the amount of overhead necessary. If the team finds estimation useful then, for agile/iterative teams, rather than give Objectives story points we recommend estimating Objectives using time units (hours or days) and using these estimates to reduce team capacity available for sprint/iteration planning.