{"id":1530,"date":"2013-04-18T06:14:20","date_gmt":"2013-04-18T14:14:20","guid":{"rendered":"http:\/\/lookforwardconsulting.com\/?p=1530"},"modified":"2024-03-05T10:26:06","modified_gmt":"2024-03-05T10:26:06","slug":"how-to-improve-your-user-stories","status":"publish","type":"post","link":"https:\/\/thescrumacademy.com\/es\/2013\/04\/18\/how-to-improve-your-user-stories\/","title":{"rendered":"How to Improve Your User Stories"},"content":{"rendered":"

Why does writing user stories have to suck so much?<\/p>\n

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. \u00a0Definitely 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. \u00a0Creating 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. \u00a0That happens by leaving the office, meeting the user, talking with them and observing their environment.<\/p>\n

\"1094299_25412604\"<\/a>However, many user story workshops normally suck and are exceedingly boring. \u00a0There are a couple of reasons why and I will share some ideas to try to make them more interesting, engaging and creative.<\/p>\n

I think one of the main reasons why story writing sessions suck is that awful user story template<\/a> many consultant and trainers ask Product Owners and Teams to follow. \u00a0IMO, the classic template has the Product Owner focused on the wrong thing – defining the feature. \u00a0What concerns me \u00a0the most is the format of the classic template pushes all the responsibility to define the feature on the Product Owner.<\/p>\n

However, when did the Product Owner in Scrum become the solution provider? \u00a0I was under the impression that in Scrum, the Product Owner in collaboration with the Team defines the features and the acceptance criteria. \u00a0If the Product Owner is providing the answer to an engineering problem,\u00a0I can see why Team members are not that engaged or interesting in writing stories. \u00a0I can see why people might think user story sessions are boring and not very creative. \u00a0The Product Owner, in addition to their job, are doing the job of the Team. \u00a0Trust 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.<\/p>\n

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. \u00a0The 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. \u00a0This 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. \u00a0In addition, what we see is an underpowered \u00a0and underutilized Scrum Team overlying on genius, creativity and energy of one person, the Product Owner. \u00a0In 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.<\/p>\n

I propose this new template which will encourage collaboration, dialogue and correct separation of roles in Scrum.<\/p>\n

“As a USER, I want VALUE by\\through FEATURE”<\/p><\/blockquote>\n

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. \u00a0Instead 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. \u00a0Once that is clear, the Team can propose a solution and together with \u00a0the Product Owner craft the wording of the feature and acceptance criteria. \u00a0In addition, the new template encourages healthy role expression in Scrum and supports the values and principles of respect, collaboration, accountability, self-organization and trust.<\/p>\n

OK – we got the new template and people focused on the right responsibilities. \u00a0How do we actually make the meeting not suck? \u00a0I am a firm believer that people need to be “warmed up” in order to think creativity and discover innovations. \u00a0My 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. \u00a0Since I do not speak a lot about Gamestorming, please check out GoGamestorm.com\u00a0since they have TONS of good techniques you can use to explore.<\/p>\n

Here are three which could help and you can find many more on the site.<\/p>\n