JV: Can you explain what exactly is speed grooming?
AD: Yeah, so it's a very structured twenty-five minutes, assuming you can do it co-locative. If you're remote you probably need to do an hour. It's a very structured format for talking at a high level of scope. Not any of the actual details for a story, but talking at a high level; what do we really want to accomplish for this story and does it meet our definition already?
You get through that with that help. Really understanding enough to implement the story but understanding enough that high-level design, interactions, and dependencies have been identified, and the right implicated parties have been notified; “Hey, we're going to be working on this. We can depend on your API. Can you help us next week?”
JV: When you're working with teams, how have they taken to the idea of the speed grooming?
AD: People like it. People feel like, “Ok, now we understand what we're supposed to do.” It's something that came from, like I said, watching advanced agile teams, watching to see what they do in the field. Then trying to find a way to get new teams to copy those same behaviors. When people do this, in the beginning it feels a little rigid, but after a while it starts to click and they're really excited about how quickly they can get through planning while, at the same time, still be in a state of just-in-time decision making.
JV: A little bit of a formality at first, but then once you get familiar with the regimen, it sort of comes a little naturally and it fits in with the sprinting session.
AD: Right. This is a training-wheels technique because pretty soon, and it depends on the team, but pretty soon the groups realize, “Ok, we get what we're supposed to be doing.” They evolve from doing this twice a week at twenty-five minutes a pop to doing it ad hoc. A product owner with a couple dubs here and there.
“Hey, I got something new coming from the business. Who can sit and talk with me about this? Let's speed groom it.”
Maybe then we have something that's with the whole team saying, “Here's the proposed design we came up with: Anybody have any concerns? Any estimates? Does it meet our definition of ready?” It becomes a lot more fluid then this regimented twice a week at twenty-five minutes a pop.
JV: What constitutes a great story?
AD: A great story, I like to call it a thin vertical slice.
JV: A thin vertical slice. Explain.
AD: Basically meaning, it can be done very quickly. That is one to three days. No task under it is going to be more than four to twelve hours. If you have ten tasks, that could be a huge story. Still, in calendar time, it could be done in about three days. That's the thin part of it. The next part of a good story is that it's a vertical slice. That vertical slice means that we can implement it.
We have everything we need to do to implement it, to deliver business value. Maybe what we're doing is we're preventing errors that our client or our business customer is manually rectifying an identifier. Patient record identifiers. They're having them manually dedupe them or something like that.
It's hard to write a story that's not technical to deal with that technical kind of problem. At the same time, it delivers a huge amount of business value. We find a way to express business value. That change to the system, that defect is now a vertical slice.
JV: It's almost like getting something that's so technical and explaining it so it meets the business objective. Making it a little bit clearer to understand.
JV: You talk about in sessions about a customer-empathy mindset. What is this type of mindset?
AD: What we're doing is we're trying to understand not necessarily what they asked for, but we're trying to understand what their goals are. We're moving beyond the literal request. As Henry Ford said, “If I ask customers what they want, they'd say they want a faster horse.” That didn't get us a car. We're trying to help our developers get to a spot in which they understand so well what the business goal is, they can innovate something that's better than a faster horse.
JV: It goes more beyond the product, itself.
JV: Can you explain the role of persona mapping?
AD: Persona mapping is a way to quickly fill up a backlog when you don't know what's coming down the pipeline; when you haven't done any work to do initial planning. This is when you first start on a team or when a team does not have released plans. What we do is we identify all of the users, or stakeholders, of our system. Write them out on individual index cards, for example.