Why does writing user stories have to suck so much?

I recently heard from a colleague that they were looking for some ideas, tricks, tips and techniques to make user story writing more innovative so they can build a delightful product.  Definitely a good idea, but running a good meeting where everyone is engaged, participating and using their brain is not going to create a delightful product all by itself.  Creating a delightful product means you understand and appreciate the user’s needs better than your competitors and that does not happen during a story writing workshop.  That happens by leaving the office, meeting the user, talking with them and observing their environment.

However, many user story workshops normally suck and are exceedingly boring.  There are a couple of reasons why and I will share some ideas to try to make them more interesting, engaging and creative.

I think one of the main reasons why story writing sessions suck is that awful user story template many consultant and trainers ask Product Owners and Teams to follow.  IMO, the classic template has the Product Owner focused on the wrong thing – defining the feature.  What concerns me  the most is the format of the classic template pushes all the responsibility to define the feature on the Product Owner.

However, when did the Product Owner in Scrum become the solution provider?  I was under the impression that in Scrum, the Product Owner in collaboration with the Team defines the features and the acceptance criteria.  If the Product Owner is providing the answer to an engineering problem, I can see why Team members are not that engaged or interesting in writing stories.  I can see why people might think user story sessions are boring and not very creative.  The Product Owner, in addition to their job, are doing the job of the Team.  Trust me – the Product Owner role is time consuming enough that they do not need to take on this additional responsibility of building the product as well.

As a result of the interactions fostered by the classic template, the Product Owner often arrives at user story sessions with a predefined notion about the feature, the engineering solution they want to deliver and a weak understanding of the value the feature provides the user.  The Team assumes that since the Product Owner has “figured out” the feature it must be right and there is little or no dialogue about the solution.  This is a common situation in Scrum and the net result is boring meetings, user stories that do not leverage any sort of creativity of the Team and a profound lack of innovation.  In addition, what we see is an underpowered  and underutilized Scrum Team overlying on genius, creativity and energy of one person, the Product Owner.  In essence, we have returned the manager to Scrum, but in this time they are in the form of the Product Owner bossing people around and telling them what to do.

I propose this new template which will encourage collaboration, dialogue and correct separation of roles in Scrum.

“As a USER, I want VALUE by\through FEATURE”

To me, the format of this new template focuses the majority of the Product Owner’s thinking in the right area – what value is the Team going to provide the users.  Instead of picking apart the solution defined by the Product Owner, most of dialogue in the user story session can be spent understanding the value, the user needs and the constraints.  Once that is clear, the Team can propose a solution and together with  the Product Owner craft the wording of the feature and acceptance criteria.  In addition, the new template encourages healthy role expression in Scrum and supports the values and principles of respect, collaboration, accountability, self-organization and trust.

OK – we got the new template and people focused on the right responsibilities.  How do we actually make the meeting not suck?  I am a firm believer that people need to be “warmed up” in order to think creativity and discover innovations.  My recommendation to improve a user story session would be to dedicate about one-third to one-half of the session to explore the features and requirements using some tools from Gamestorming or Innovation Games.  Since I do not speak a lot about Gamestorming, please check out Gamestorming.com since they have TONS of good techniques you can use to explore.

Here are three which could help and you can find many more on the site.

  • 3-12-3 Brainstorming: brainstorming in large groups normally falters for two reasons – it favors people who think fast and large groups tend to evaluate ideas rather than brainstorm so people stop contributing.  3-12-3 Brainstorming addresses these weaknesses by focusing on small groups and allows participants to create and present a complete concept  to entire group.  The key to this activity is phrasing the question to start the brainstorming.
  • Draw the Problem: any technique that involves drawing usually generates a ton of insights and creativity.  To get the most out of drawing be sure to have lost of interesting colored markers, stickers and big sheets of paper (we want big ideas, not little ones).  Some people are uncomfortable with drawing so reinforce that these exercises are not art contests, but ways to capture ideas.  I normally allow people to work in pairs or triads if they are uncomfortable working alone.
  • Heuristic Ideation Technique: I like this game since it creates mental tension in the minds of the participants by asking them to combine two seemingly incompatible ideas.  It is in that tension that we must use our creativity and different life experiences to arrive at an innovative solution that harmonizes the two ideas.  I believe the key to this exercise is not to march across the columns left-to-right (or top-to-bottom), but jump around the cells as ideas occur to the participants.  Remember, there is no “one right answer”.