Back to List

Struggles with Story Writing (Agile Transformation Pain Point #10)

Rachael Wilterdink Rachael Wilterdink  |  
Nov 08, 2018
 
Story Writing struggles are so common and impactful that we offer a half-day training workshop on it for organizations.
 

Avoid technical stories

Many Product Owners don't have a lot of experience writing requirements, and if you're a BA like I am coming from a waterfall world, you tend to like to write a lot because that's what you used to have to do. But now user stories are meant to be from the user or the business perspective.

I've seen some teams that tend to write stories from a technical perspective, and I would caution against that. I am not a fan of a “technical story”. Unless a story has value that is delivered, and that is measurable and usable by the end user customer, then you're not delivering anything of value. Avoid those types of stories. Always try to look through the lens of your customer or your user.
 
struggles with story writing
 

Slicing the cake

Another thing many organizations struggle with is slicing the cake (see right). In the old days of software development, you'd have to do these horizontal layers one at a time until they were all done, and you wouldn't get any value delivered until the very end.

In agile, you're going to take a thin vertical slice of just what you need to do that action –such as pay with PayPal –and you're going to go through all the horizontal layers to get something that completely works. It just does that one very narrow function, but you have everything you need to get value out of that right away.
 
slicing the software development cake
 

Don’t forget to include the “why”

If you've ever heard the user story format, “(as a [role], I want [something], so that [I can get some benefit])”, the why is the “so that” part of the story. Many people tend to get lazy and forget to do the last part because it's not convenient. They actually have to think about why. But I caution against not including that. You really need to have the “why” for the development team. It gives them the context that helps them understand what value is provided by doing the story. Without that, they're not going to know why they're doing it, and they're probably going to ask you anyway. You might as well put it in there.
 

Write stories at just the right size

Finally, writing stories at the right size is also very difficult. Think about Goldilocks and her experience with the “just right” porridge. In this case, you want to have stories that can be completed within a Sprint, and it's great if you can right-size your stories so they're all comparably sized. It's not always possible, but you also don't want to have stories that are too big. Those are epics.

Epics are stories that would need to be decomposed into smaller stories to be delivered within a Sprint. An epic could never fully be delivered within a Sprint. On the flip side, you could also have stories that are too granular. In that case, you might want to consider combining some to make it a larger story.
 

Get the free eBook

This is the tenth of 20 blogs on 20 Agile Transformation Pain Points (and how to avoid or manage them). To read them all right now, download our free eBook.
 
agile transformation pain points ebook
Agile

 

Love our Blogs?

Sign up to get notified of new Skyline posts.

 


Related Content


Blog Article
Pre-assigning Work to Team Members (Agile Transformation Pain Point #14)
Rachael WilterdinkRachael Wilterdink  |  
Dec 13, 2018
This pain point is something you definitely don’t want to do. Agile and Scrum teams are meant to be self-organizing. They should volunteer to pick up assignments, not be assigned. Development team members are volunteering to do stories, and they might want to learn something new &ndash...
Blog Article
Taking on Too Much Work in a Sprint (Agile Transformation Pain Point #13)
Rachael WilterdinkRachael Wilterdink  |  
Dec 06, 2018
Some teams are super ambitious, and they just think they can climb a whole mountain in a single Sprint, but the whole goal with agile is to maintain a sustainable pace. Take on only what you really think you can get done within your Sprint. Don't overestimate your velocity, and don't...
Blog Article
Not Having a Definition of "Done" or "Ready" (Agile Transformation Pain Point #12)
Rachael WilterdinkRachael Wilterdink  |  
Nov 29, 2018
Most people who are familiar with agile are familiar with the concept of definition of Done. This is something that the team should create when they are first formed, and they should continually be inspecting and adapting that at each of their retrospectives. They can update that definition of...
Blog Article
Diagramming & Modelling Tips for Business Analysts
Kurt WondraKurt Wondra  |  
Nov 20, 2018
Among the many responsibilities of Business Analysts, including Backlog Management and Communicating and Collaborating with our teams, the skill of diagramming and modelling is one which seems to be more taboo than mainstream. Have you ever wondered why that is?   One observation I&rsquo...
Blog Article
Forgetting to Have the "Conversation" (Agile Transformation Pain Point #11)
Rachael WilterdinkRachael Wilterdink  |  
Nov 15, 2018
You may have heard the three C's of agile: the card, the conversation, and the confirmation. Many people will have the card: they'll write the story, but they'll forget about the other parts. They'll just write it in a silo and not get any feedback. They won’t actually...