Where there is no struggle, there is no strength.
User stories can be challenging to get right. I remember struggling with them the first time I worked on a Scrum team. I fall in the camp of too little detail. In my waterfall days before that, I would rarely have or read the business requirements. Things were always in a state of flux so clear requirements were much like the Loch Ness monster. You heard stories of them but, never saw them. Let’ go over a few common struggles people run into.
Started to early
Stories occasionally get pulled into the sprint that was not quite ready. I am eager to get work done. As a scrum master, I would overlook some of the missing information. My team did a good job of learning this. They would review the items and see if there was something missing. Try to develop a checklist that helps guide whether you have all the information. I have seen many teams do this and each checklist is a little different.
Start easy tasks
As we see in this post sometimes developers start easy tasks first and never get to the more challenging tasks till later in the sprint. One thing I tried to do is have the easy tasks left until later in the sprint to fill time later. Start the hardest ones first and give yourself the most time on those. After awhile the team will get used to this and jump on the harder tasks right away.
I remember in college I took some economics classes. The professors always would talk about widget production. This fictional item of production threw me for a loop. I like to visualize things. A widget is hard to imagine. Economics was not of much interest to me, so my imagination would wonder. When teams start to look at the size of user stories it can be hard to determine if it is an epic or user story. Or what part can we complete in the sprint.
Mike Cohn from Mountain Goat Software says, “Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case.” He reminds us to re-examine the work left and check to see if it is still important. Perhaps we may need to split some of the user stories up. I am glad Mike reminds us to look for the root cause. Each team is different and we need to learn from our mistakes.
There are many stages to the user story life cycle. In this post they break it down into fives stages. The first stage is “Not Started” when it comes out of the sprint planning. Then once we begin to work on it, the story is “In Progress”. The team completes the work and it becomes, “Done.” Depending on the approval of the user story it can be “Accepted” or “Rejected.” Occasionally stories will get “Cancelled” as they are no longer relevant. These are not hard and fast rules so your team could create their own statuses.
Roman Pichler is a big name in the agile world. He shares some great tips here. He reminds us that the user comes first. So keep the customer or user perspective on top of your mind. Create the stories collaboratively. Just as it points out in the Agile Manifesto, “Individuals and interactions over processes and tools.” Refine the story until it is ready to go. Rarely does something start out ready it takes some time to sort out. His last point reminds us not to just use user stories. There are many other things to try along with maps, diagrams, storyboards, and more.
Occasionally people do something that feels a bit icky. Like taking some old waterfall requirements document and shoehorn it into a user story. People try to keep their waterfall habits in an agile world. Perhaps it is an acceptance criteria list that looks a little too long. Agile is founded on conversations and many of these novel-like documents are a conversation avoidance technique. If something smells in your user story make sure and take out the trash!