A piece of advice I find myself always giving to Product Owners goes to the very heart of how empiricism (the basic workflow of a good Scrum team) is supposed to work. It makes all the difference in the world to effective product ownership.

The advice is this:

“Load your Sprint with a little bit of a lot of features, instead of a lot of one or two features.”

The reason for this piece of advice is simple: the whole idea in empiricism is the concept of doing some work, inspecting and learning from the work (including getting feedback), and then deciding what to do next and adapting our plan accordingly. This is the fundamental reason for the existence of the Sprint Review.

The Sprint Review

The Sprint Review has exactly two goals:

1. Get everyone on the same page with the product or service. What did we do? What didn’t we do? What did we learn while doing it? In speaking about the product or service, what other ideas have emerged?
2. Decide what is the right next thing to accomplish (no, we aren’t doing Sprint Planning here – Sprint Planning is specific, the Sprint Review is more about general direction).

The metaphor I use in my classes is simple: imagine you are in a shopping mall that is new to you and you want to find a specific store. You walk in and find a store directory. Usually the first thing you look for is where you currently are in the mall. You look for “You Are Here.” Then you find the store you are looking for, and then you decide which way to go from where you are currently standing. If the mall is particularly large and complex, you might walk a bit in the right direction, and then find another directory to help you from there.

This is exactly the purpose behind the Sprint Review. Where are we? What have we learned? Where should we go next?

A Lot of a Couple Features

Many product owners, perhaps despite their training, are still fixated on building their products one feature at a time. As a result, they tend to load a lot of work on one feature into a Sprint with the goal of completing (or almost completing) the feature in a single Sprint.

When they get to the Sprint Review, they get feedback on the one or two features they built. Stakeholders and customers provide feedback about things they like and things they don’t like about the two features and the product owner updates the product backlog accordingly.

But there’s a better approach.

A Little of a Lot of Features

Imagine loading your Sprint with a little bit of work on seven to ten different features. The team builds a feature that searches for students in a university, but it only searches on student last name and only displays student ID and last name in the search results. The team builds a feature that allows a student to add a class to their course schedule, but it doesn’t care if there’s already a course in the student’s schedule at that day and time. The team builds a login capability that doesn’t actually check the password yet.

But, nothing’s actually ready for production, so what good are any of these features?

This is where REAL empiricism comes in. During the Sprint Review, the developers demonstrate what was built. Stakeholders and customers in the review start asking questions about the student search capability. Could the results be sorted? What if there are lots of students in the search result, is there a way to further refine the search without starting over? What if a student’s last name is spelled wrong in the search or in the student record? One customer has a light bulb moment and asks, “what if I want to print the results of the search, could I do that too?” The product owner answers, “we never talked about that before, but I’ll add it to the Product Backlog and we can discuss it more fully later, OK?”

The team moves on to the “add course” feature and the customer starts asking questions. “Can a student replace a class with another class?”

“What if the student adds a course already on their schedule, but it’s a different section on a different day and time? Can they be automatically dropped from the section that is already on their schedule.”

The team moves on to the login capability and the stakeholders ask, “Hey, we thought this would be using single sign-on when we sign on in house.” (in other words, when a university employee accesses the product, the network figures out their sign-on credentials). The product owners answers, “we haven’t talked about that yet, but I’m really glad you brought it up now. Let’s discuss further after we’re done here.”

Light Bulb Moments

Empiricism, in addition to being a method for deciding what to do next based on the evidence around you, is also really effective at creating “light bulb moments.”

Light bulb moments are when stakeholders, customers, users, and even developers look at a feature demo and go, “Wow! Hold it a second! I just had an idea!”

Sometimes we hear it as, “Hey! Now that I see this, can we do X too?”

The whole point about product demonstrations during Sprint Reviews is to get feedback, including creating light bulb moments.

Why a Little of a Lot is Better Than a Lot of a Little

By working on a little bit of a lot of different features in a single Sprint, your team can open the door to a significant amount of feedback for the least amount of work. Insights that result in changes to the feature can be captured early, before significant rework is needed. You may even discover features that, upon doing the demo of a little bit of the feature, are no longer needed by the customer. you may discover features that, upon doing the demo of a little bit of the feature, no longer need everything they said they needed, cutting back significantly on the work you planned to do.

When we plan a lot of one or two features into a Sprint, we get so much work done during the Sprint that, by the time we are getting feedback from stakeholders and customers, it’s too late to get any serious benefit from their feedback that doesn’t result in significant rework.

Try it. In your next Sprint Planning, make sure that your product backlog items are nice and small (items your team can attack and complete in three days or less). Then, load a little bit of a lot of features into the Sprint and watch what happens.

You’ll not only magnify the learning, you’ll magnify the feedback too!