The second in a short series of articles on crafting effective, well-formed objectives as part of the SAFe® Program Increment (PI) / Big Room Planning activity.
The series will cover:
- Why do we need PI Objectives when we have Features?
- Writing good PI Objectives
- PI Objectives and the PI Planning Process
- PI Objectives Beyond PI Planning: Reaffirming and Monitoring Your Commitments
As we saw in the previous article in this series, objectives are not just a repetition of the features that the team plans to do; there’s far more to them than that. In this article we look at the practicalities of writing good PI Objectives.
2.2 Where do objectives come from?
As we saw in the first article it is essential that the objectives come from the teams, this ensures buy-in, unleashes the creativity of the team members, and helps create a better plan. It does though beg the question where do the teams find the inspiration for their objectives?
We have found that there are 5 areas that every team should consider when forming their objective, each of which can influence the phrasing used when writing the objective itself:
Features - Generating value by delivering one or more Features.
The most obvious source of Objectives are the features that the team has taken. In this case the Objectives should not simply be a re-stating of the Feature’s name. They should capture the results of any negotiations that have occurred during planning; the Feature request that came into planning is not necessarily what ends up being done.
Objective: Provide “Flexible Search” with fuzzy character matching (see the Flexible Search notes for details) that displays the results in a list ordered by closest match.
Key Results: The search allows users to find items that match and are close to the given spelling.
Often Features can be delivered incrementally in order to provide early access and de-risking of future deliveries. Objectives can describe the sequence and scope of the intermediate deliveries
Objective: Provide an early access “Flexible Search” with just exact character matching.
Key Results: Find items so that the end-to-end browse and buy (checkout) process can be demonstrated and de-risked.
|Try to use phrasing in the PI Objective drawn from the title of the feature as this will make it easier to tie the objective back to the feature after the event.|
Collaborations - Helping other teams do Features.
Many features need inputs from several teams; the collaborations where one team is helping another make good objectives. Indeed, the receiving team will be listening out for the objectives from the other teams that have agreed to deliver work or information to them.
Objective: Provide team Alpha with an API to allow items to be added to the shopping cart by the end of Sprint 1 so that the results of searches can be purchased.
Key Results: The Shopping Cart is successfully integrated with the search and browse functions allowing individual items, or sets of items, to be added.
Not all collaborations are document or code handovers, sometimes they are true collaborations, an architectural gathering to map out technical strategy for a feature or future work.
Objective: Collaborate with team Alpha and System Architects on Wednesday 4th to establish the Shopping Cart API to allow items to be added to the shopping cart for future purchase.
Key Results: API agreed. Stubbed functionality coded and submitted to version control that allows both teams to develop, and test, in parallel.
|When writing help objectives, construct the objective so that the name of the team that you’re helping comes first, followed by the help that you are providing them. When the objective is read out during presentations the other teams will start to pay attention when they hear their name mentioned; then they’ll be listening when the objective explains how you intend to help them. If the objective is constructed the other way around then by the time a team hears their name and starts listening the help they are going to receive has already been described and they’ll have missed it.|
|Again try to use the phrasing from the feature description so that it can be traced back to the feature if necessary.|
Internal work – Keeping the train running smoothly.
Refactoring, code clean-up, keeping the lights on, relentless improvement, and much, much more are all things that the train needs to do but aren’t necessarily coming through the Program Backlog. Teams should be empowered to add work that they know they need to do to their own backlogs; but this internally generated work must be made visible to honour the principle of transparency and allow tracking and negotiation around it. This internally generated work can be aggregated into one or more objectives.
Objective: Reorder the tests in the automated regression test systems to run the end-to-end performance and smoke tests ahead of the repetition of the functional Feature tests.
Key Results: Ability to determine a working build ahead of the detailed Feature level validation so we can spot systemic failures faster and repair them quicker.
|Focus on the key results of the internal work and the value that it provides. If teams can clearly articulate why it is valuable the stakeholders are less likely to question the work and demand that other work be done in its place.|
Capacity Reservations - To deal with the known-unknowns.
These objectives occur when teams know that there is work to be done but they don’t know exactly what that work is going to be until it appears; typically these are operational incidents such as emergency defect fixes or support duties to assist frontline staff. The team can set capacity aside to deal with this work and honouring the principle of transparency it can be made visible by turning it into an objective.
Note: In these cases it is essential that it is clear what the capacity is going to be utilised for and to bound the amount of capacity that will be consumed. This can then be tracked and the numbers used to influence the reservation in subsequent PIs.
Objective: Provide frontline support to the call centres answering queries, analysing problems, and providing work arounds and hot fixes as necessary.
Key Results: Support calls are dealt with within 12hrs. No more than 10% of the team’s capacity within the PI is spent on support.
Learning and Growth – Gaining knowledge
Whilst this could be considered Internal Work many organisations are striving towards Enterprise Agility and one of the key cornerstones of Enterprise Agility is to have a Learning Organisation. It therefore makes sense to explicitly ask all our teams to be thinking about how they will learn and grow. Without learning and growth there will be no improvements to how we develop our solutions and the solutions themselves will be anchored by their historical context and unable to change. It is important to make the learning objectives visible so that we can demonstrate that the teams and the train are preparing and evolving their skills ready for the future.
Objective: Learn about non-Latin mark-up in HTML to prepare ourselves for the content translation functionality that is on the roadmap for the next PI
Key Results: Demonstrate at least two pages using non-Latin character sets, spending no more than 2 days of the team’s effort.
2.3 Writing SMART Objectives
Objectives should be SMART. You’ve probably already encountered the SMART acronym with respect to your own personal objectives, and it’s regularly referenced in training material on writing objectives, but how does it apply within SAFe’s PI Planning context?
|What is SMART|
|SMART is an acronym that you can use to guide your goal setting. Its criteria are commonly attributed to Peter Drucker’s Management by Objectives concept. The first known use of the term occurs in the November 1981 issue of Management Review by George T. Doran. Since then, Professor Robert S. Rubin (Saint Louis University) wrote about SMART in an article for The Society for Industrial and Organizational Psychology. He stated that SMART has come to mean different things to different people, We have gone with the definition used in the SAFe® training materials.|
Specific (simple, sensible, significant)
In the previous article we discussed The Relationship of PI Objectives to Features: Clarifying the Benefits Hypothesis; the concrete instantiation of how the team intends to approach the problem. This needs to be specific, clearly stating the action and the intended outcome as concisely and explicitly as possible.
As seen in the examples above we favour a two part format where part one communicates the action and its purpose whilst part two clearly specifies the key results. Both need to be specific. For example, what is the purpose of the action? Look for key words such as:
We make the key results specific by making them measurable.
Measurable (meaningful, motivating)
In the previous article we discussed how Good Objectives focus on describing the measurable results: Look for the evidence / results - is this clear and measurable? Has the team called out the key results that will prove they have achieved the objective?
Watch out for “weasel” words, typically adjectives, that don’t mean anything such as:
All of these need some form of quantification in order for the objective to be measurable, and some kind of target for the objective to be achievable.
For Quicker, have a target for how much Quicker you’re expecting to make the system.
For Easier & Simpler, what are the specific concrete actions that are going to be done to make the system Easier or Simpler.
The more concrete the target that is being aimed for the easier it will be to judge and score later on when the feature has been delivered. Beware: more concrete doesn’t mean we lock down our options; don’t form a strict plan that cannot be deviated from! What it does mean is that we understand how we are measuring the targets that we are setting for ourselves, so that when we do evaluate options within the execution of the Program Increment we know that they’re achieving the desired goals.
The measures may be descriptive, binary (yes/no), quantitative or provide a range. However if the results are to be measured then they must be achievable.
Achievable (agreed, attainable)
As well as ensuring that key results themselves are achievable the team should also be thinking about whether or not they are equipped to achieve them. Do they the skills and capabilities needed? Is achieving the objective within the team’s influence and control? For an objective to be achievable the team needs the skills required to deliver the results; or the plan needs to contain time to acquire those skills.
As well considering whether or not the team is equipped to achieve the objective they also need to think about whether or not the objective itself is realistic, relevant and reasonable.
Realistic (relevant, reasonable)
The team should also be thinking about whether or not their plan to achieve the objective is realistic. In fact before they start planning they should consider whether or not it is realistic for them to take on the work - sometimes the objectives themselves are not relevant or reasonable, and therefore not sensible objectives for the team. If the objective does not seem worthwhile, if we’re not the right people to do it or it is clearly not the right time to take it on then, even though it is specific, measurable and achievable, it is probably not a realistic objective.
For the achievement of the objective to be realistic the team also needs to have set the right amount of time aside at the right time within the sprints to satisfy any internal collaborations or external dependencies. They also need to understand all the additional activities that they are expected to perform in order to ensure that the work is done properly; this will be driven by the Definitions-Of-Done at Story and Feature level.
The underlying plan for delivering the objective needs to be realistic, making any assumptions and risks visible. The plan should deal with a reasonable “bad-day” scenario; the estimates shouldn’t be too optimistic. Recognize factors that cannot be controlled and avoid making “happy path” assumptions. Plan to do everything; if things happen quicker, or a better solution emerges that involves less effort, then execution gets easier and the team can always pull work forward from Program Backlog or spend the gained time clearing technical debt.
It must also be realistic to achieve the objective within the Program Increment. If the objective is too grand in its scope then it may require more than one PI to complete. This means it is not a realistic PI objective.
Time-bound (timely, time sensitive, time/cost limited)
Within SAFe® the default time-bounding for a PI Objective is the timebox of the PI itself; but some objectives might need to be more tightly time-bound. In particular the collaborations where there is an agreement in place to deliver something by a certain point in time; but don’t constrain yourself more than you have to. If it’s not explicitly needed by a certain date give yourself the freedom of anywhere in the PI. Look for the anchors. Is the timeline fixed or flexible? Is there a customer or collaborator that depends on the timely achievement of the objective?
|When objectives are tied to milestones, often releases, our experience is that using the name of the milestone or release is more understandable than a fixed date. As a bonus; if the date of the milestone moves then the objectives relating to it don’t have to be rewritten, they remain valid!|
Sometimes the objective isn’t just time-bound by a fixed delivery date or a specific time-box; sometimes you want to limit the amount of time that is to be spent on attempting to achieve the objective. Often these kinds of time-limited objectives are called Spikes - some of these may already be explicitly identified as backlog items but many of them will emerge as the objectives themselves are formed. Make sure that any time-limits are explicit in the objective.
|When objectives are time-limited state the maximum amount of time to be spent on the objective as part of the Key Results. This is often clearer than trying to integrate it into the objective statement and ensure that it is measurable and considered when the objective is evaluated.|
SMARTER - going beyond SMART objectives
Many authors, including Professor Rubin, have noted that the definition of the SMART acronym may need updating to reflect the importance of efficacy and feedback. To this end, some authors have expanded it to SMARTER to include extra focus areas Evaluated and Reviewed. The good news here is that we don’t need to extend the acronym as these are built into the SAFe® framework as part of both the PI planning process itself and the PI’s Inspect and Adapt activities. We will be exploring this more in the final two articles in this series.
Next.. PI Objectives and the PI Planning Process
In the third part of this series we’ll look at how PI Objectives and the PI Planning Process interact.