The third 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 (this article)
- PI Objectives Beyond PI Planning: Reaffirming and Monitoring Your Commitments
We have provided a PDF version of these articles, combining all of the content for offline working or study if required. You can download this here, or continue to scroll down this page to read part one in our series, and navigate each of the pages in turn, enjoy!
Download the set of full articles!
abstract
As we saw in the previous articles in this series, objectives are not just a repetition of the features that the team is doing; there’s far more to them than that. In this article we look at how PI Objectives are a key part of the PI Planning Process.
objective creation within pi planning
Objectives are not an input to the PI Planning process they’re the output; they are created to describe where the team’s time and effort will be spent in the upcoming PI. Teams should try to avoid waterfalling the writing of Objectives; don’t leave it until the very end! Write objectives up as you plot work into sprints and/or as work is negotiated with other teams.
Teams should be applying the Lean and Agile principles to the act of planning itself. Teams should be taking one feature at a time from the backlog and adding it to their plan; but at the same time the teams should be deferring elaboration of the detail until later. In practice this means breadth not depth. Teams should put a rough plan together early in the planning process and have a full set of candidate objectives ready by the end of the first break-out even if they haven’t finished planning all of them. This is so that the Business Owners can do a proper job of scoring the objectives during the second break-out on Day 2. The act of scoring the objectives will inevitably result in negotiations that will change the details so better to defer elaboration of those details as late as sensibly possible in the process to avoid effort being wasted on detail that subsequently gets negotiated away.
With a rough plan assembled and candidate objectives laid out the team can continue to add more detail; particularly focus on the early iterations as the detail required for execution will be needed sooner than the later iterations.
| Useful Trick: |
|---|
| Write the objectives on Post-Its® whilst they are still being edited and elaborated. All the edits and corrections can be made on the Post-It; the entire Post-It® could be rewritten from scratch if the edits are sufficiently large or a set on minor edits has become too numerous. Only commit the objective to the large sheet of flipchart paper at the last moment; literally in the last 5 minutes of the Team Breakout the Team Member with the neatest handwriting copies them off of the Post-Its® onto the flip-chart. Commit to the paper too soon and you can guarantee that within 5 minutes somebody will have suggested an edit! |
getting to good objectives
Crafting the words for a good objective is itself an iterative process. In this example we’ll look at the steps that a team have gone through to get to a good objective and examine some of the thought processes that drove development of the objective.
The team have grabbed a feature called “Flexible Search” and have been negotiating and planning it during a PI Planning event.
Their first attempt at an objective is:
| Provide Flexible Search |
Essentially just a restating of the feature name; this is likely not specific enough to capture any negotiations that have occurred during the planning event itself. As a coach my questioning to the team will often start with “Are you planning to do all of it?” Upon questioning the team reveal that scope negotiation has occurred so the results of that negotiation get written into the objective.
| Provide Flexible Search with basic matching and a Levenshtein Distance Algorithm. |
“Basic” is one of our trigger words; it’s not specific. The team need to rephrase that to explain what their idea of “Basic” is.
| Provide Flexible Search with exact character matching and a Levenshtein Distance Algorithm. |
“Levenshtein Distance Algorithm” is too specific; it locks the team into a specific technical implementation. Whilst we want to be specific (from the SMART acronym) about the business outcomes desired, it would be preferable to preserve the design options available to the team during execution, following SAFe® principle #3. (see also our SAFe Principles Cards for more detail on the principles) Flexibility in this dimension allows the team to explore other algorithms with the aim of achieving a better business outcome. The specific technical phrasing is also something that the stakeholders might struggle to understand. The team are steered towards rephrasing this in terms of the outcome expected and using language the stakeholders will understand.
| Provide Flexible Search with exact character matching and fuzzy matching. |
Do we need to clarify any other assumptions that people might have? In this instance is this just the back-end processing of the search or are the stakeholders expecting to see the results listed?
| Provide Flexible Search with exact character matching and fuzzy matching and display the results in a simple list. |
“Simple” is another trigger word; it’s not specific.
| Provide Flexible Search with exact character matching and fuzzy matching and display the results in a list ordered by closest match. |
In this context “and” is another trigger word. Isn’t exact character matching just a form of fuzzy character matching where all the characters match? What do we mean by fuzzy character matching? In this case the team needs to do two things: 1) include the Feature Card in their negotiations, and 2) start to think about the key results that they are expecting.
By referring to the Feature Card they find that the level of fuzzy matching desired has already been defined, and that there are already some negotiable acceptance criteria that hint at the expected results. Using this information they add more notes to the Feature Card and prepare their final revision of the objective.
| 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. |
The journey to a good objective has captured the negotiations of planning, ensured specificity whilst preserving flexibility and clarified any assumptions.
uncommitted objectives
Uncommitted objectives1 are used to indicate risk that an objective might not be achievable; teams are not required to make a commitment to delivering their uncommitted objectives. By having the escape valve of uncommitted objectives the commitment to the main objective becomes stronger.
Some of the criteria for Uncommitted Objectives are:
- The last feature in the last sprint of the team’s plan. If something goes wrong and other features take longer to deliver then this feature is likely to be knocked off the back of the plan for this Program Increment.
- A feature with a significant external dependency where the external supplier is notoriously bad at delivering on time. If the delivery was expected early in the Program Increment and there is sufficient flexibility in the plan to move things around if things slip then classing as a stretch might not be needed; but if the delivery were towards the end of the Program Increment and leaves very little room for manoeuvring then classing as stretch is a useful signifier.
Can the highest priority Feature from the backlog be an uncommitted objective? Yes. Use of uncommitted objectives is to indicate risk and if there is significant delivery risk then it should be a stretch objective. If the stakeholders requesting and prioritising the features don’t like that then encourage them to work with the team to de-risk the delivery; the stakeholders may have more authority over any external factors and can help the team.
Teams and stakeholders must learn to strike a balance and embrace some degree of risk; only significant risks involved in delivery should be criteria for classification as an Uncommitted Objective.
| Useful Trick: |
|---|
| Enablers need to be turned into objectives as well. One team that I was working with was struggling with turning their Enabler Experiments into Objectives; they repeatedly got hung up on the fact that they didn’t know the result that the experiment would produce therefore they couldn’t craft a “Specific” objective around it. The trick was to take a step back and ask whether the experiment itself was specific, yes it was. Is “running” the experiment measurable, yes; the measure is “do we have a result?” Do we have the resources both physical and mental to make the experiment Achievable and Realistic, yes they did. The time-bounding was still the PI. The objective became running the experiment not predicting its result. As long as the experiment can be run; that we can’t predict the experiment’s result is not a grounds for making it an uncommitted objective. |
scoring objectives
As part of the activities occurring during the Team Breakout Session on Day 2 the Business Owners are asked to score the objectives. SAFe® uses the phrase Business Value; but our preference is to use talk about importance to the business rather than value.
There are three reasons for scoring the objectives:
- Early Contact – Uncover the assumptions
- Data Point for team sequencing
- Closing the loop – Predictability to plan
Early Contact: Scoring the objectives forces the Business Owners to read and understand the objectives; this will uncover any assumptions that either the team has around what the business wanted or assumption the business has around what the team is expecting to deliver.
| We were working with a major global household name; they had a new product that they wanted to to get to market. The senior sponsor was attending the PI Planning event, this was his endeavour and he had real skin in the game, the outcome of this was either going to get him fired or make him famous. Halfway through Team Breakout on Day 2 we send the sponsor out into the room with the instructions “go score the objectives”. Half an hour later he’s toured the room and comes back to the table reserved for the central roles and we asked him how he felt. “Empty.” Even our enthusiastic optimism struggles to put a positive spin on “Empty”; we had to start questioning what had gone on. It turned out two of the teams had grabbed business functionality from the backlog whereas the other two teams planning were, to use the sponsors phrasing, “doing techie s**t.” The teams were setting up the build system, delivery pipelines and underlying system infrastructure which were all necessary but an indirect contribution to the overall goal rather than direct business functionality. On the afternoon of Day 2, after Final Plan presentation, the senior stakeholder was asked “Does he accept the plan?” Yes, slightly grudgingly, he accepted the plan and he went on to raise his hand with a score of 4 for the subsequent confidence vote. Consider how this could have turned out had he not had early exposure to the objectives; his response to the teams presenting their plans to get the necessary infrastructure up and running would have been questioned with “What is this techie s**t you’re doing?” in front of an audience of all the other teams. Early exposure allowed us to anticipate and fix the issues and maintain the momentum of the planning event. |
Team Sequencing: The team’s goal is to try and maximise the amount that they’re delivering back to the wider organization; they should try to target the most important objectives and the scoring provides that information. Ultimately at the team level technical issues will primarily drive the sequence in which stories are accomplished; the team might need to go through some less important objectives to unlock the ability to deliver the more important objectives. If bad things happen then the team also knows which objectives are most important to the business and can focus on them and defer the less important objectives.
Closing The Loop: The score will be used to close the loop on predictability of the team’s delivery of the plan. Closing the loop will be covered in part 4 of this blog series.
The score is range between 1 and 10 and providing a range is important; if everything is given the same score them it provides no useful information everything is equally important or unimportant. We have seen organisations which have enforced a ruling where “there must be a 1 and there must be a 10 in the scorings” in order to force the Business Owners to think about providing range. Scores are not intended to be comparable across teams and the sum of the scores is also irrelevant; when we close the loop it will using percentages of the total score not the absolute total score.
| Useful Trick: |
|---|
| At one planning event the two stakeholders scoring the objectives could never agree; one was tasked with new functionality the other business-as-usual and they regularly came into conflict. Rather than forcing them into agreeing on a number, which would have caused issues, they scored the objectives individually and the independent scores were totalled up. If they both cared about an objective, they’d both score it high and the total would be nearer 20. If one cared about it and the other didn’t it would score around 10. If neither cared, it was down towards 2. The actual range used doesn’t matter; it’s the fact that it is a range is what makes it a useful input for the team. |
SAFe® refers to the group scoring the objectives as the Business Owners; this group isn’t every little stakeholder of the release train but those few stakeholders that typically have true accountability (typcially financial) for the success of the work being undertaken. Typically this is no more than 2 or 3 people. We would also recommend that the most senior technical figure in the room be part of the Business Owner group as well; their role being to explain the technical aspects of the plan (like architectural enablers) to the non-technical people in words and language that allows the non-technical people to understand the benefits.
communication of intent
During the PI Planning event team’s need to communicate their plan to the rest of the release train on two separate occasions, Draft Plan Review at the end of day 1 and Final Plan Review in the middle of day 2. These plans need to be communicated quickly but accurately without digressing into team level technical detail. The assembled audience wants to know what the outwards value deliveries are from the team and the collaborations needed to help with value delivery. Just reading the team’s objectives should provide this focus; if a team has to extemporize when reading their objectives then it’s a sign that the objectives aren’t clearly describing the team’s intent.
next.. beyond pi planning: reaffirming your commitments
In the fourth and final part of this series we’ll look at how the objectives created during PI Planning are used during execution of the PI.
#1 Prior to SAFe 5.0 Uncommitted Objectives were known as Stretch Objectives. The renaming occured because people were misunderstanding the intent of Stretch thinking they were “nice to haves if time allows” rather than their true intent of expressing risk.
or
More Great Agile Content from Ivar Jacobson International:
- How Many Features do you need for PI Planning
- WSJF & Feature Slicing
- All about the PI Planning Management Review & Problem Solving
- Secrets of Dispersed PI Planning
- Estimating in Story Points