In Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way to get from the big picture to the ranked backlog is via deliverables in the form of small (user) stories. See the wikipedia page about user stories. Notice that they are a promise for a conversation.
I talked about feature sets in the first post, so let me explain that here. A feature set is several related stories. (You might think of a feature set as a theme or an epic.) Since I like stories the team can complete in one day or less, I like those stories to be small, say one day or less. I have found that the smaller the story, the more feedback the team gets earlier from the product owner. The more often the PO sees the feature set evolving, the better the PO can refine the future stories. The more often the feedback, the easier it is for everyone to change:
- The team can change how they implement, or what the feature looks like.
- The PO can change the rest of the backlog or the rank order of the features.
I realize that if you commit to an entire feature set or a good chunk for an iteration, you might not want to change what you do in this iteration. If you have an evolving feature set, where the PO needs to see some part before the rest, I recommend you use flow-based agile (kanban). A kanban with WIP limits will allow you to change more often. (Let me know if that part was unclear.)
Now, not everyone shares my love of one-day stories. I have a client whose team regularly takes stories of size 20 or something like that. The key is that the entire team swarms on the story and they finish the story in two days, maybe three. When I asked him for more information, he explained this it in this way.
“Yes, we have feature sets. And, our PO just can’t see partial finishing. Well, he can see it, but he can’t use it. Since he can’t use it, he doesn’t want to see anything until it’s all done.”
I asked him if he ever had problems where they had to redo the entire feature. He smiled and said,
“Yes. Just last week we had this problem. Since I’m the coach, I explained to the PO that the team had effectively lost those three days when they did the “entire” feature instead of just a couple of stories. The PO looked at me and said, “Well, I didn’t lose that time. I got to learn along with the team. My learning was about flow and what I really wanted. It wasn’t a waste of time for me.”
“I learned then about the different rates of learning. The team and the PO might learn differently. Wow, that was a big thing for me. I decided to ask the PO if he wanted me to help him learn faster. He said yes, and we’ve been doing that. I’m not sure I’ll ever get him to define more feature sets or smaller stories, but that’s not my goal. My goal is to help him learn faster.”
Remember that PO is learning along with the developers and testers. This is why having conversations about stories works. As the PO explains the story, the team learns. In my experience, the PO also learns. It’s also why paper prototypes work well. Instead of someone (PO or BA or anyone) developing the flow, when the team develops the flow in paper with the PO/BA, everyone learns together.
Small stories and conversations help the entire team learn together.
Small features are about learning faster. If you, too, have the problem where the team is learning at a different rate than the PO, ask yourself these questions:
- What kind of acceptance criteria do we have for our stories?
- Do those acceptance criteria make sense for the big feature (feature set) in addition to the story?
- If we have a large story, what can we do to show progress and get feedback earlier?
- How are we specifying stories? Are we using specific users and having conversations about the story?
I’ve written about how to make small stories in these posts:
- Make Stories Small When You Have “Wicked” Problems
- Three Alternatives for Making Smaller Stories
- Feature sets in How to Use Continuous Planning
- Reasons for Continuous Planning
The smaller the story, the more likely everyone will learn from the team finishing it.
I’ll address ranking in the next post.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
| Reference: | Product Owners and Learning, Part 2 from our JCG partner Johanna Rothman at the Managing Product Development blog. |
