Goals and CUPS for Sprint Reviews

 "If you don't know where you're going, you'll probably end up somewhere else."

When presenting at a Sprint Review, it is important we shed as much light as possible on the value of the features we've completed.

In order to do so, I will present a framework to help in achieving this.

Every story is completed by a solution to a problem in a given context that is driven by an end goal or an ideal state.

So first off we start with a

Goal

To have a problem, in the first place, we need a goal or an end ideal state we want to reach.

If the stories in your backlog are created with that in mind, then they should, by design, reflect the "Goal" (Possibly within an epic that itself reflects a superset goal).

Example

Imagine while presenting I say "We now have a configuration file to declare the properties for the DB service".

Without knowing the goal behind it, one cannot see the value it brings to the product.

However, If I were to first say we intend to "Launch the platform DB service with 8 GB of RAM in order to ensure optimal performance".

Defining this goal within the review, sets the mind frame of those listening into the potential value provided by the solution.

Now the configuration file solution is starting to make sense. However it still is missing some information - context.

Context

The context in which information is delivered shapes assumptions and perceptions about that information.

Information taken out of context is often meaningless.

People reach conclusions based on the framework within which a situation is presented.

What's with this "optimal performance" statement? What about it? Where are we today with performance anyway?

Here is where we should relate the "static goal" to what we've achieved, where we are, what is involved, how has this impacted our product.

Relating our current position with respect to the goal sets the frame within the minds of the audience.

Underlying Problem

OK great, so I understand how important performance is to us and how far off the optimal point we are.

Why not just launch the thing with 8GB?

Here's were we can talk about complications 

For example, "Prior to this sprint, it was impossible to launch the DB service with unique configuration - all config was set globally and inherited by all services."

"Setting the config to 8GB meant all services will launch with 8GB and we do not want that."

Solution

Alright, so I can see the goal now, I have a context to work with and place me comfortably within so that I can now safely and simply think within that frame. I see the problem that is hindering us from reaching our declared goal.

Now we can go ahead and state the solution!

I can finally say "We now have a configuration file to declare the properties for the DB service, in fact, the development allows config declaration at the granularity of each service".

The audience sees the true value of the solution due to the problem it solves, within a certain context, that achieves or brings the product closer to an ultimate goal.

Conclusion

For a quick mnemonic - remind your audience of the Goal and present with CUPS!