Agile with External Clients: Master User Story Facilitation

The Agile with External Clients series continues today with the topic of requirements facilitation and management, with user stories as the primary vehicle for the task. This article’s mantra is captured by one of my favorite phrases around Agile, which comes from the last sentence of the Agile Alliance website’s entry, What is Agile Software Development?:

…to craft the code and the team such that the inevitable requirements churn was not a crisis.

This is the core difference for me between Agile Software Development approaches and the phased, non-iterative processes that dominate much, if not most, of the industry. Over the years, the most effective tool I have had in my arsenal for transitioning groups into more iterative, collaborative approaches to gathering, refining, and prioritizing requirements has been user stories. When I say user stories, I am referring to the format and philosophy laid out by Mike Cohn in his indispensable book User Stories Applied: For Agile Software Development. I am not referring to the user stories as defined in Behaviour-Driven Development (BDD), but that is another topic for another time.

As a consulting or professional services group, your clients will rarely see your team using the more technical and development-centric aspects of Agile and Scrum, unless you embed delivery teams on-site at the client. Even then, the focus of their interaction with your team is translating needs into working software. In light of that, everyone on your team needs to master the art of user story writing and facilitation.

For your clients to truly understand the power and flexibility of an Agile approach, they need to feel the difference between handling requirements in Agile and however they have been doing them before. If they are accustomed to heavy up-front design, analysis, and specification, they need to see how this approach doesn’t require that they pretend to know the future, just enough to know the core of what they build and how much they want to initially invest. Together, you can knock out those key pieces of functionality and decide what else to add collaboratively, with the invaluable insight of seeing part of the application working already.

If the client has been handling requirements with a complete lack of process, with managers or stakeholders delivering requirements by walking up to a programmer’s desk, expert user story facilitation can show them how a bit of lightweight structure and cross-functional interaction serve to flesh out requirements in a way that weeds out those painful gotchas that so often plague the last stages of a project. A product backlog of concise, easy-to-read stories also paints a clearer picture of how much functionality and effort they are throwing into this project. I have found this provides a context for discussing choices and scope management with clients like this who are accustomed to a more chaotic mode of operation.

To master user story facilitation, your team members need to focus on a few key skills. First, team members need to be excellent at writing user stories, and the only way to do this is practice. Pair newcomers with veterans so they can watch and learn from them. Do you have internal projects for frameworks you develop and maintain? Make yourself express the work as user stories to get realistic practice so that your group doesn’t have to start their learning in front of the client. After all, you have a very narrow window to solidify trust with clients; more on that in another installment.

Second, team members need to develop prowess as user story facilitators. They must guide and encourage open discussion in a cross-functional group. This requires exceptional interpersonal skills, which should come as no surprise. Use the The Principle of Slices Instead of Layers to guide the group out of the tendency to express effort in terms like “the dev work”, “QA’s part”, and “the DBA tasks”. Guide the group toward expressing effort in bits of user-centric functionality that will involve all the cross-functional tasks as emphasized in The Rule of Concept to Customer. Are the stories centered on a group of services? Fine, the remote client that calls the service is the customer. When a facilitator leads a group through this transition, the result is an approach to requirements gathering and refinement focused on what we are making for our users and accounting for everyone’s contribution in making that happen.

There’s plenty more to say about facilitating user stories successfully, but we’ll stop there for now. Just remember that expertise with user stories will be one of the most direct ways to show customers that this is a refreshing and effective approach to managing requirements that makes the most of their valuable time and the money they are spending with you.