Deep Product Discovery
This meeting occurs before the start of an timebox. The team meets with the team lead and product developer to see which user abilities are ready to be accepted into the next timebox. The team might estimate the user abilities, but they will accept or reject the work they think that they can complete in the upcoming timebox.
- The team doesn’t understand how to complete the user abilities they’re trying to implement
- Developers and testers frequently argue about when something is finished or what it should be
- Product developers are frustrated by what the team is building
- The team expends considerable time and resources trying to learn what a story is supposed to be, or what the users want
The primary benefit of this practice is an efficient use of the team’s time. When a team attempts to combine the StoryRefinementMeeting, the planning meeting, and timebox kick off meeting, then a subset of the team debates user abilities and meaning of user abilities, terms, and intent, while the rest of the team is bored and checks out. Symptoms of “checked out” teammates include laptop, tablet, and phone usage, internet surfing, game playing, doodling, yawning, and side conversations.
The more powerful, and less recognized benefit, is that by sharing the user abilities with the teams earlier, you allow the team to think about these issues and remember (or discover) information that they’re not going to recall if you put them on the spot in a team meeting. Developers have long recognized that our brains have the ability to do background processing. Our brains solve problems when we present them with information and then do something else (see Pragmatic Thinking & Learning for details). This mode of work harnesses those background processes and allows the teams to understand the work they’re beginning much more completely.
- Lunch and Learns are held consistently and provide meaningful, relevant content that helps to increase the team’s capabilities (100pts)
- Lunch and Learns are occasionally held, and sometimes provide something valuable (10pts)
- No one volunteers to present a topic (-25pts)
- Lunch and Learns are never held (-100pts)
- Lunch and Learns are consistently canceled due to higher priorities (-150pts)
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
- The product developer collects a set of user abilities for the team to work with in the next timebox. Collect 150% of what you think they can complete.
- Review each story with at least one developer and one tester before the meeting. Use this time to learn more about the story and ensure it contains sufficient detail
- The product developer assembles the team and presents candidate user abilities
- The team discusses each story and decides if they understand the story well enough to work on it
- The team (often) sizes the story using points or t-shirt sizes (relative sizing)
- The team decides how many of the user abilities they can complete in the upcoming timebox
- At the end of the timebox, the product developer attends the demo, and the team shows their work
- The product developer decides if the story is what they expected… they either accept or reject each story. Significant differences of opinion mean the user abilities need more initial discussion.
- See if everyone involved had the same level of expectation about the user abilities
- See if the team is able to complete their commitments
What Does it Look like?
Story refinement is the product developer having a series of daily meetings (some scheduled… some ad hoc) with developers, testers, and customers. In these meetings, story details are debated, discussed, sometimes argued, but understood. The team decides what the report should look like here instead of waiting for the demo to discuss the number of fields. Or the preferences pane, or the work flow, or …?
A planning meeting is the team coming together to review user abilities again, this time in priority order, and to estimate relative story size, before deciding how much work they’ll accept into the timebox.
- The product developer tells the team what user abilities they’ll work
- The team is told who will work on which story
- The team consistently accepts far more work than they can complete
- The product developer brings incomplete user abilities that aren’t ready for the team to discuss
- No one but the product developer has seen the user abilities at the time the user abilities are unveiled at the planning meeting
- As a team, work towards completing your commitments, not becoming “Yes man” team that over commits, but can’t deliver
- Work on acceptance criteria that the product developer, developers, and testers can all understand and agree to use
- Do enough preparation that the planning meeting is fast
Exercises to Get Better
- Try to completely prepare one story every day (during the timebox before the planning meeting)
- Work on a story alone, then with only a developer, then only with a tester, then both. What is each perspective missing?
- Do a root cause analysis on any story rejected by your team. What didn’t they understand? How can you make new user abilities more clear? Different language? More detail? Pictures? Sketches?
- Do a root cause analysis on any story rejected by the product developer. Did the team not understand the level of work required? Was the story written poorly? What went wrong? How can we avoid this in the future
How to Teach This Practice
The best way to learn this is to watch others doing it, then do it yourself. But that’s true of most practices, isn’t it?
Try pairing with another product developer who’s already doing this. Shadow them for an entire timebox and watch how they work. Help them work on their user abilities.
Then try it yourself. Follow Jerry Seinfeld’s idea of not “breaking the chain”, or the writer’s habit called “Daily pages”. Anything you want to do well, you must at least touch at least once every day. So every day, as a product developer, touch at least one story. Read it. Review it. Try to add some detail. Some days you might only spend five minutes on a single story, but other days you’ll find yourself pulled into discussions that last half a day.
Every day that passes, you should make progress with at least one story. That ensures you’ll have a solid backlog ready for the team in the planning meeting.
Many larger planning meetings take all day. Some are multiple days. This is bad. Try to schedule your planning meeting for no more than half a day when you start, but know that with proper groundwork done ahead of time, you can wrap this meeting up in an hour.
How To Fail Spectacularly
- A product developer telling the team which user abilities, and how many, they’ll accept into an timebox
- Emailing the team with incomplete user abilities and asking them to fill in the details on all of them
- Emailing the team ahead of time and asking them to size user abilities via email
- A team that consistently pulls in more work than they complete
- Teams that realize their management is measuring “points” as a metric, so they artificially inflate their estimates in order to look more efficient
- The team is seeing user abilities for the first time in the planning meeting