More on this book
Community
Kindle Notes & Highlights
by
Jeff Patton
Read between
October 12 - December 23, 2019
A right-sized story from a user’s perspective is one that fulfills a need.
A right-sized story from a development team’s perspective is one that takes just a few days to build and test.
A right-sized story from a business perspective is one that helps a business achieve a business outcome.
If you use one of the available tools that help organize groups of Agile stories, it may support the concept of bundling stories up into a theme. You might simply refer to the theme by what it really is: your next release, the feature, or the stories relevant to a particular type of user.
It seems that Jira is at odds with this approach since it does not really have themes and Epics are made to be closed. Seems more useful to me to use epics as themes so you can drive towards a release.
Use opportunity discussions to agree the problem is worth solving—to make a go-forward or trash decision.
Use discovery conversations and exploration to find a small, viable solution.
Use deep-dive story workshops to discuss the details, break down stories, and really agree on specifically what we’ll build.
Use conversations as you build to fill in details and give feedback on what’s being built.
Use metrics and face time with users to really learn if your target outcomes were met.
If this were a project, you’d be done—because you shipped it. But you just made something. It’s a product. And a product’s life starts when it’s delivered.
Effective product owners surround themselves with the people they need to make good decisions. They incorporate the expertise and opinions of many. But, in the end, when resources are constrained or the success of the product is at stake, they must make decisions. And there’s always someone who’ll be unhappy with that decision. My friend Leisa Reichelt puts it well: “Design by community is not design by committee…design is never democratic.”
It’s rare if not impossible for a single person to possess the business, user interface design, and engineering skills necessary to find that valuable-usable-feasible sweet spot. That’s why the most effective organizations use small, cross-functional discovery teams that work together to find that right solution.
The ideal size for the team is two to four people—dinner-conversation-sized so the members can quickly build shared understanding.
This is hard to pull off at Alianza due to the cross-team coordination needed to pull this off.
In this anti-pattern, one person in a conversation takes the client role, while the other takes the vendor role. It’s the client’s job to know what he wants, and to explain the details to the vendor. That’s what we call “requirements.” It’s the vendor’s job to listen, understand, and then think through a technical approach for delivering what the client asked for. The vendor then gives her estimate—which in software lingo actually means “commitment,” and is the reason why developers often fear giving estimates without thorough investigation.
The real tragedy here is that the person in the client role understands his problem better than he’s able to predict what will solve it. And the person who understands the technology is often the most qualified to solve the problem because she knows how the technology she’s working with can help. What’s more, most technologists honestly want to help. They want to know the things they’re building are put to good use. But, in the client-vendor anti-pattern, conversations about problems and solutions are replaced by discussions and agreements about requirements. No one wins. One of the goals of
...more
The whole stack of these stories is what I call an opportunity backlog.
I like this name. Better name for the Innovation table.
Design Studio Recipe
Seems like a good way to ideate.
If you were listening closely just now, you caught the secret to prioritization. Specific business outcomes drive focus on specific users, their goals, and the activities they’ll engage in with your product. Focus on those activities drives focus on the specific features and functionality users will need to be successful.
The prioritization error that most people make is to try to prioritize features first. Prioritize specific business goals, customers, and users, and then their goals, before prioritizing features.
This leads me to one of the biggest mistakes people make, and that’s actually believing their minimal viable solution will be successful.
Ha. Love it.
Using elements of design thinking helps us really understand the problems we’re solving, so we don’t solve problems we imagine people have.
Steve had written a book called The Four Steps to Epiphany (K&S Ranch) in which he asserted that the first thing you need to develop isn’t a product, it’s customers.
Where a typical design process may take weeks or months to validate a solution idea, a Lean Startup process usually takes just days.
In the bad old days, you’d have guessed and pretended you weren’t. In a design process, you’d not have allowed yourself to guess. You would have anyway. But you’d have pretended you weren’t. So just stop pretending.
all conversations are made tougher by trying to include too many people. If many of those people aren’t interested or motivated to participate, you’re doomed. You know the people I’m talking about—the ones pretending we can’t see them playing with their smartphones under the table.
It’s those unpredictable things that you’ll observe when users begin to adopt and use your software frequently that yield the most insight. If you plan for time to really measure and observe outcomes, you’ll be rewarded with people who really love your product and a product that’s really valuable for your organization.
