More on this book
Community
Kindle Notes & Highlights
You’ll need a small group that includes a developer, a tester, and people who understand users and how the UI will look and behave — UI designers or business analysts in some organizations.
now focus on answering the question: exactly what will we build?
helps the team make decisions and arrive at confirmation: the acceptance criteria for what we’ll choose to build.
Ahead of the workshop, let the team know what stories you’ll be workshopping. Post it on a wall, or otherwise broadcast it. Let team members
discuss the problems we’re really solving, and other alternatives we could build to solve them.
What will we check to confirm this software is done? How will we demonstrate this software later when we review it together?
Work together as a group to split up big stories, or “thin” out stories by removing unnecessary extras.
My first foray into the world of an Agile project team in my role as a business analyst was a cold, hard lesson in the power of collaboration over the written word.
Steve, the project manager, facilitated a team retrospective to focus on the problem. This retrospective resulted in a number of key takeaways, including abandoning story narrative documents, including the business and delivery team in story elaboration, and ensuring a set cadence for backlog grooming and story elaboration.
conversations are made tougher by trying to include too many people.
Allow team members to opt in to these conversations. If later they complain about the decisions made, make sure you invite them to be there next time. If everyone wants to participate, try using a fishbowl collaboration pattern like the one described in the following sidebar. This way, interested people can drop by, participate if they want, and leave if they find they’re not missing anything exciting.
So I’ll break it into “cupcakes” — small, complete parts that aren’t ready to ship, but that boost my confidence that I’m on the right track as I move through this book.
In a traditional software process, that “inspecting and removing” stuff would be called bad requirements. But, when you’ve got your Agile hat on, it’s just learning and iterative improvement.
If I were building this feature, I’d do the basics first across the whole application before I moved on to making things better and then best.
Cutting and polishing takes time, and a bit more patience.
Development Cycle Planning Recipe
For those on the product team, make time to work together with team members ahead of the planning session. Dig into details, split larger stories, and consider multiple options.
series of short, half-hour, ad hoc story workshops
Start by discussing the big goal for the upcoming cycle. You’ve chosen some stories to work in. How does that group of stories help advance the solution you’re trying to deliver?
Give the team an hour or so to break into small groups and work together on the stories. If you’re a product owner, UI designer, or business analyst, stay close by. Observe if you like. But be ready to answer questions that’ll help them move fast.
What’s important is for the team to be clear about what they believe they can get done in the cycle.
Try dialing back a story from better to just good enough. That should make it fit.
An easy visualization to build during that workshop is a simple map. You might be mapping only the three or four steps the user takes using a feature you’re discussing.
As you begin to discuss acceptance criteria, write them on sticky notes and add them into this mini-map.
We used Pivotal Tracker and Basecamp, but all these other people weren’t going to use those tools.
This big visual wall of sticky notes was critical for building a bridge between the people developing the software and the people who needed it. It’s what they needed to help them visualize what was going on and when, and to actively participate in making decisions.
Break stories down progressively, and just in time.
Each one of those agreements provides an opportunity to break down a story even further where each story satisfies as little as one agreement.
big groups of people don’t work effectively
not all in the same room at the same time.
we break stories down progressively over time with lots...
This highlight has been truncated due to consecutive passage length restrictions.
To avoid a backlog filled with lots of tiny stories, take a bundle of stories that go together, and write all their titles on a single card as a bulleted list. Summarize those titles with a single title on your new card. Voilà, you’ve got one big story.
If your stories are in an electronic backlog, get them out onto cards or sticky notes.
It’s wonderful for deep bug lists, too.
Bundle them with other higher-priority bugs in the same area of the system.
Map only what you need to tell a story about your feature.
When adding a feature into an existing product, map a little ahead of where the feature begins in your users’ story, and a little beyond where it ends. Don’t map your whole product.
Hidden within all these strategies is the assumption that a lot of the stories we come up with are big. But, actually, a lot of them aren’t.
lots of little things that are dead obvious — things you wished you’d have thought of before shipping, but you didn’t.
For those things I don’t have an opportunity discussion, or pull together a group to do product discovery, because it’d be obvi...
This highlight has been truncated due to consecutive passage length restrictions.
Start by discussing the software built as a result of the stories.
Write stories to correct quality issues you see in the product.
discuss your discovery work of the last cycle.
Total the number of stories you agree are done. This is your velocity.
if you’re having fun, I promise you’ll be able to go faster.[
This group will need some insight on the discussions you had as a team and any tradeoffs you made.
Stakeholder Product Review Recipe
Invite everyone who’s interested. This is a big public review. Anyone interested is welcome. Make sure your whole team is there. Seeing others’ reactions to what they’ve done, either positive or negative, helps remind them that what they’re doing matters.
The only thing that trumps an executive opinion is a cold, hard fact.
what success means.
