More on this book
Community
Kindle Notes & Highlights
So the idea is telling, and you know you’re doing it right if you’re generating energy, interest, and vision in the listener’s mind.
If you’re not getting together to have rich discussions about your stories, then you’re not really using stories.
Because this is a conversation, the listener can ask questions and it’s the back and forth that will correct that understanding and help everyone arrive at some shared understanding.
If we build what we agree to, what will we check to see that we’re done?
When it comes time to demonstrate this later at a product review, how will we do that?
Whatever we bring into the conversation we’ll mark up, write on, correct, and change.
And don’t forget to take some “vacation photos” before you leave. Photos of what you’ve created will help you recall all the details of the conversation that would be difficult to write down.
The template goes like this: As a [type of user] I want to [do something] So that I can [get some benefit] The folks at Connextra used this simple template to write the descriptions of their stories.
But when we start a conversation using that template, we end up in a much richer conversation than if we’d just talked about a file uploader.
Backlog grooming, for example, took place in week one of the iteration with a small group (project owner, project manager, business analyst, technical architect)
The conversation was about tweaking and improving our stories, and we ignored things like prioritization, story points, and so forth. It worked.
We ignored Trello, which we were using for our digital card wall at the time, and focused instead on the face-to-face conversations, sometimes standing at a whiteboard. Working as a group, down in the detail, is actually pretty rewarding, and as it took only about 20 minutes each time, it wasn’t too much of an overhead either.
All of this makes me sad. Because the real value of stories isn’t what’s written down on the card. It comes from what we learn when we tell the story.
But it’s not best practice — it’s a best learning practice.
Please don’t just talk about “the user.” Be specific. Talk about which user you mean.
It’s OK to talk about the services and the different systems that call them. It’s OK to talk about specific UI components and how the screen behaves. Just don’t lose sight of who cares, and why.
You can keep “poking it with the why stick” for a long time to really get at the underlying reasons
Talk about when they’d use the product, and how often. Talk about who else is there when they do.
Talk about what goes wrong
You’ll find it takes lots of conversations to think through some stories.
Without explicitly talking about how (and if you’re a developer, I know you’re thinking about it), it’s difficult to think about the cost of the solution.
Ask questions, and genuinely try to learn from each other.
You’d think a company that focuses on building tools used for keeping and sharing information electronically would use its own tools — “eat their own dog food,” so to speak — and you’d be right that Atlassian does. But it also understands how to have good face-to-face conversations. When I walk around the Atlassian office in Sydney, I see the walls covered with sticky notes, whiteboard drawings, and screen wireframes. If you look closely, you’ll see that the sticky notes reference ticket numbers in those tools the team relies on. They nimbly move back and forth from tools to physical space.
...more
What’s Really on a Story Card?
But, whatever you do, please don’t start referring to your stories by their number. If you do, it’s a sure signal you haven’t chosen a very good title.
Value You might have lengthy discussions about the relative value of one thing over another. Some might use a numeric scale. Some might annotate cards with high, medium, or low.
If you really care about results, identify specific metrics you’ll track after the software is released to determine whether the software was successful.
The only thing that’s required on your card is a good title.
it’s just a token you’ll use to plan with.
When I tell people how companies like Atlassian use tools, they’re usually surprised. They’re often surprised because they’ve been trying to use tools as a replacement for whiteboards and sticky notes.
But, if you’ve got to accomplish this task with others working remotely, this is tough.
When collaborating remotely, use tools that allow everyone to see, add to, and organize the model concurrently.
Tools like Atlassian’s Confluence offer a rich wiki for storing not just words, but also pictures and video.
The trick is using the right tool for the right job. Don’t try to use a really great tracking tool to build shared understanding. And don’t struggle to do complex analysis on a whiteboard.
If you and a group of people have worked together to understand what should be built, and if you’ve documented all the important things someone needs to know to build it, you may be very tempted here to hand it off to someone else.
Sharing stories is reasonably simple. Someone who does understand the story, and the information collected that helps tell the story, needs only spend a little time retelling the story to the next person who needs to learn.
Effective discussion and decision making goes best with small groups of two to five.
Let small groups work together to make decisions, and then use continued conversations to share the results with everyone else.
We’ll test by watching them use the software to reach a real goal they’ll normally need to accomplish using the software.
It’s a powerful motivator to see people struggling to use your product, especially when you were so confident they wouldn’t need to.
And for each one of those things, you should write a story card with your ideas for improving the software.
Each new story we create software to support is something new.
“For every story you write, you need to put three into your backlog of stories.”
“Well, if you have to write something on them, then write what you want on the first card, and on the second card write ‘Fix the first card.’ Then on the third card, write ‘Fix the second one.’ If you aren’t going around this cycle three times for each story, you’re not learning.”
You’ll need to plan on learning from everything you build.
Validated learning over working software (or comprehensive documentation)
Try using stories to drive the making of anything, whether it’s software or not.
lots of who, what, and why questions.
context
When it comes time to make the cake, she’ll have a list of things she’ll need to do —
