SCRUM - are user stories ever done?

I have been doing SCRUM for over a year now and overall applied the framework of SCRUM with good success. Although a simple framework, it is hard to apply. I decided to write this article because I feel the terminology of SCRUM is misleading a little and maybe I can give my option on the definition of “done”. One of the core elements of SCRUM are “user stories” and writing them and defining them is not simple, but at the end we do it and we have nice stories everyone understands. During our grooming sessions and planning session we feel that we have a good set of stories ready to go into our next sprint. Using poker planning everyone votes on the complexity of the stories with story points and everyone in the team comes to an agreement on the final votes, and off we go and the sprint starts. For the sake of this article let’s write about one story which allows you to add a user to a web form application. The user story was simple enough, “As an administrator, I want to be able to add users to my system, so I can manage access to the application”. There was more to it, some acceptance tests that only valid users should be added, using some validation rules. Overall not much more details than that. A user in this example has only 3 fields, name, last name and e-mail. The development started and off we go into implementing this story. During our demo part of the sprint, issues came up. The product owner said, “how come the save button is enabled if there is invalid information on the screen?” the developer said “You never said anything about the save button and validation in your story…” Then another torpedo come right in “I made some changes to the screen, forgot to press save and got into another screen… how come it didn't worn me that I will lose my changes”. Again the developer said, “I didn't see anything about navigation in the story”. All of a sudden, another team member said: “The error messages are not too clear; maybe we should change the fronts”. We go over the definition of done, and see that the meet everything on the list. The story is unit tested, we have reviewed the code and we implemented support all the way from the UI to the DB. Yet, the product owner is not happy with it, and after some discussion the team decided the story is not done. We need to fix it up and move it to the next sprint.

Done = Good for now

In SCRUM we use the word “done”, and sometimes “done-done” and this gives us the idea of that story should be complete and that we should never go back to it. But this is false. We see this every day at work. People, developers and product owners alike always tend to change their mind and add feedback, not during planning but mostly during a demo. This is really just because of how we think and how our brains work. We love to “touch” it and “feel it” and then we have an opinion, “This is cool!”, or “I don’t like the way this works”. Sometimes you don’t always think about some requirements when you write a story, review a story, or when you plan or task a story, you only start thinking about them when you actually “see” or “use” the story in the software. Even if everyone loves the way we did it, our customers really have the final say, and may ask you to change the way a feature works, and again that feature or story is not done. So the word done is misleading, and when we ask ourselves “is this done?” we tend to think of “perfect complete user story or feature”. The truth is that we will never get perfection, there is always a room to improve and therefore we will never be done. The question we should ask ourselves is if the story is “good”, or “good for now”, or “are we are happy with this”.

The definition of done

But, wait a minute – we got the “definition of done”, so if we meet everything on that check-list we must be done. In SCRUM terms this is true and the definition of done is a good thing. It allows us to have quality, by forcing us to look at other things than just the development. For example, we can have documentation, code review, unit tests and deployment elements in there. Still, you may meet everything in that check-list and still find out that the story may not be complete due to feedback. So what do you do now? You say the story is not done, because we didn’t think of this and that? Or do we create new stories to fill in the gap? Well, how about avoid the problem all together with a simple solution. Demo the story as soon as possible. Don’t wait for the end of the sprint to demo the whole thing, demo and ask feedback as soon as you have something to show. Sometimes it can be a screen that doesn’t even do anything, and you ask the product owner, “is this what you looking for? It can be done on the development machine and it should be done without any formal process. Let’s say our product owner is James – you should be able say: “Hey James, when you have a second can I show this story about adding users, tell me if you like it”. Normally feedback will flow immediately – product owner may notice that fonts are not clear and ask to change them. This is a simple task the programmer can do on the spot. To make sure, this demo process is done – why not add it to the “definition of done”. This way we know this must happen before moving the story to “done”. A demo can also reveal new information and features no one thinks about when writing the story. In this case, the team should get together and decide what to do. Can we continue the story in current scope and offer some value, if yes that should be the best option. After all, stories are all about offering value, and the only time a story should not be set to done is if quality was compromised by not meeting the full definition of done, and if it doesn't offer value any more due to new information.

“It’s not in the user story syndrome”

People like to know of everything up front, expecting the product owner to hand them over a story with all the details from the screen, color and specs of every detail. When the feature doesn’t work as expected, developers tends to say: “This wasn’t in the user story”. Let’s face it this is not going to happen, product owners can’t think of every detail and if they do its probably waste. I gave this syndrome a name: “It’s not in the user story” syndrome. After being a scrum master for some time, I just kept hearing this over and over again. The solution is actually to seek this information often and soon. Demo the story, so you lean of new elements of the story. If possible implement them in the current sprint, if not possible discuss these elements with the team. Always, keep talking and talk often. Normally, things will work themselves out simply by common sense and communication. A good product owner will learn to settle when he feels this is “good for now”, but not “done”. A good product owner will look for value and not perfection. We should not ask if the story is done, but rather if we can improve the feature with other features.

Can we ship the product?

So SCRUM chose to use the word “done”, and that’s OK, but don’t think of done as a done thing that will never change because it will. Sometimes, when it comes to a problematic user story which actually met the definition of done check list, I like to ask product owners, “if you had to ship the product tomorrow, is this story good for now?” if they say yes, I believe this story should be set to done and any other improvements should come as new stories.