You and your team are preparing to deploy in production a set of features. Unfortunately, some of these have the status”almost done” and it’s not clear how much longer will take until done. Straight to the point – this shouldn’t happen.

To avoid the failure of the deployment, one way is to reconsider how your team is splitting the user stories. Mastering the art of splitting will help you make a better decision on what’s valuable for the user.

In this article, I’m going to give you a few hints about how to get rid of the “almost done” curse.

Start with the output

Typically, as a software developer, when you begin working on a user story, you might be tempted to start by designing the domain model. You’ll define a few entities and their associated database tables. Then you’re probably going to think about how to query these tables. And how to combine all this data in order to send it to the user interface so that it can be presented to the user in a nicely designed HTML page.

In a matter of minutes, you already clogged your brain with too much information, thinking about too many things all at once, losing your focus on the task at hand.

I’m going to propose an alternate approach: start with the output. What is the first step that the user is going to take when using the new feature? Let’s say she’s going to click a button to load the new page. Scratch that, forget about the button. It’s just a page that loads when accessing a URL. Do that! Design and code the page that the user is going to see. Associate it with its respective URL and ship it.

Deliver small increments

You might argue that it’s not enough, that the feature is not done. The user cannot do much, if anything, on this page. That’s true, but at this point, the focus is not on the user experience. We didn’t implement the button linking to that page yet, so the users can’t even access it if they don’t know the URL.

So what’s the point? Well, the answer is early feedback. By delivering small increments, you can validate the user experience with the rest of the team: the product owner, the Q&A team, the early beta users, etc. While they work on that page, you can move on to the next increment.

Think about the next small thing that you can do. Given our initial page, it might contain a form. If the user clicks the save button without filling any input fields, then some error messages should be displayed. This is your next shippable increment: client side validation. As soon as you’re done implementing these error messages, ship your code.

Rinse and repeat! Always be on the lookout for the next small thing that you can add and ship, without breaking any existing features. At the same time, make sure that whatever you push to production can be verified by another team member, or by a user. Refactoring existing code does not fall into this category.

Zero, one, many

Let’s look at this in another way. Considering a simple CRUD feature, we can split it into separate user stories by each operation: create, read, update and delete. Reading existing records is one story. Creating a new record is another. Updating it – another one. Finally, deleting a record is a standalone story, too.

Taking into account that we’re dealing with a collection of records, we can start thinking about the simplest, smallest thing we can implement. What does the application look like when there are no records available? What does it look like when we add just one record? What happens if we add many, many more records? There are at least three user stories hiding behind these simple questions.

By following the “zero, one, many” approach, you can make sure you take slow steps toward implementing a feature that is much bigger in scope. You don’t have to think about all the edge cases at once, nor should you. Taking one step at a time ensures that you keep your focus on what is important right now.

Conclusion

The above examples are very simplified, and you might argue that the advice does not apply to your complex user stories. However, if you take a good look at your current user stories, you could see how they can be simplified, split and delivered in a more streamlined manner. I go as far as claiming that each acceptance criteria of your big user story can be re-purposed as brand new, simpler user stories.

Delivering small increments that do not make much sense on their own may seem like a radical approach, but you should try it for a change to see what happens. At the very least, being able to show and demo your progress is better than the excuse of “trust me, I’m almost done”.

Photo source