I have been “doing” user stories for a while, years now. I have been doing them mechanically without thinking about what makes them “good”. Not that I haven’t been working to make them better with each release on every project. My user stories have consistently grown better following the INVEST pattern. What I haven’t been thinking about is “why” user stories and the process through which we create them is good.
Then a couple weeks ago I was asked to help a new project with project “people” who were not familiar with agile practices prepare for the onboarding of a consulting team who is recommending an agile process for delivery. The project had already gathered comprehensive high-level requirements but there had been no visioning of how those requirements would be met. The project manager wanted to “make progress” by starting to elaborate detailed requirements while we were selecting the outsourcing delivery vendor. As I re-read the requirements, I realized that the business process was changing, and the requirements had been gathered from the current manual business processes without capturing the vision for how the centralized group would operate. I had designed the middle-ware, and had a bulk estimate for user experience for the ops team, assuming that the requirements gathering exercise that would follow the funding would contemplate their process.
I recommended that instead of a deeper dive on the existing requirements we take the time to “convert” the requirements into a structure that our agile delivery vendor will be able to understand (i.e. user stories). This idea was met with some questions and concerns so I suggested that we conduct a “trial” user story workshop with the project team – consisting of several project managers and business analysts. Before committing to this path, and to this process, and involving our customer, let’s see if we think it will be a valuable exercise.
When we finally had our “story workshop” I was prepared for a lot of negativity and “folded arms”. The response I got was completely different. I got what I always want in a requirements gathering session – engagement, creativity, ideas, smiles, questions, and ultimately unanimous agreement that this was a valuable exercise that we should engage our customer and continue.
Why did this happen? Why did five experienced PM’s and BA’s suddenly get totally sold on this process in one practice session?
1) They could propose ideas that would add value to the customer. Everybody likes to see their own ideas on the whiteboard.
2) They could begin to see how the solution would really accomplish the strategic goals of the program for risk reduction and cost reduction.
3) They could start to see the metaphors that would be implemented in the middle-ware appear as nouns in the stories.
4) They could start to see the actors who appear as beneficiaries of value propositions of the stories.
5) They could start to see the actions that can be initiated through or by the system.
While we were discussing the user stories that we were proposing, we discussed ideas about how they might be implemented so that we could envision for ourselves how the end users of the system might interact – but were careful not to get stuck on any detailed interaction or implementation – just envisioning.
At the end of our 90 minute workshop we had about 10 stories that the whole group was pleased with. We talked about how some of the ideas may not be valuable in the initial release of the product. We talked about how after we create the product backlog, we would order them in a sequence that would inform our initial release minimum viable product, and also the structure and content of future releases. We talked about how each story we write helps us understand other stories that are possible without committing to any particular implementation. Conversations after the workshop were unanimously positive.
While pondering I realized why the user story concept is “good”. Because it is both creative, and provides a way to constrain creative ideas by ensuring their ability to achieve valuable goals. It supports both the free flow of ideas, but provides a means of constraining the ideas to a consistent, useful structure. I saw how user stories began to form the ubiquitous language that allows us to describe the problem and form the solution.
No Comments