There is a bunch of Apple hype recently coming out of the most recent WWDC event, or perhaps all of them?. Like the new $6,000 cheese grater (super, sigh). I’m a bit of an Apple ecosystem fan so I noticed something in an article that we can use as an example for that common question SPC’s get from teams and Product Managers. How do I write a SMART PI Objective?
First we really need to understand the value proposition. What “value” are we trying to build and transport to the customer/user, and the business? We know that in the technology business this means creating and/or changing system behaviors in the system of systems, the ecosystem, the products, et cetera.
In this example, you can see that Apple is bragging about the 9ms Apple Pencil latency, and improvement from the previous generation/release of the product.
Scenario – Thinking out loud
If we were able to go back in time and watch Apple’s teams using SAFe (they don’t AFAIK, but they do use “Agile”) to plan and develop this backlogs’ new NFR (non functional requirement), we would expect to see a PI Objective, perhaps derived from a conversation like the following.
“We have been getting feedback through customer reviews, surveys, and product testing (leading/lagging indicators) that the customers really want the physical experience of drawing/writing to be as close as possible or the same in the digital version of our product. The 20ms performance of the first and second generation Pencil is still not quite there yet. We need to improve the interface performance so that it is more like using a regular pen or pencil.”
We know now that the first and second generations of the Apple Pencil had a performance on this NFR at around 20ms. In this objective writing scenario the Product Manager is hoping to improve on the NFR performance even more. Remember, NFR’s constrain the backlog. In SAFe, this means that business and enabler features are developed to meet the criteria of the NFR’s that constrain the program backlog. Check out the quote below from the Macworld article. It captures the key elements of a SMART PI Objective.
Specific – improve the latency of the pencil so that it will write better
Measurable – we can easily measure latency performance of changes in the software
Achievable – the team/ART has the capacity and capabilities to refactor/redesign/rethink or create new code that will enable the new performance goal to be met
Realistic – the pencil already performs well at 20ms and based on recently completed architecture enablement the runway is clear for our team to experiment with refactoring to enhance performance
Time-bound – the team has the capacity to commit to the objective of reducing latency by 11ms.
PI Objective – Improve response latency of the Apple Pen h/w, f/w, and s/w interfaces by 50% so that the writing experience will be improved
Assumptions for example on the Apple Pencil product
There are existing features of the system of systems (iPad Pro and Pencil) that will probably need to be changed to achieve the objective. There are likely many new [business] and changed features and enablement [enablers] that will also need to be completed to achieve the objectives. In some cases, an objective may also be achieved by completed a single feature.
Remember, if you are changing an existing feature we don’t need to create an entirely “new” feature in the system to describe it. Start with what was and use stories and enablers where applicable to avoid batching, waste, and complexity. Revise rather than recreate an entirely new artifact. For those working in high compliance spaces may note that traceability is easier without complex branching and duplicative structures.