Ask HN: How do you write vertical sliced user stories?

My team is trying to use agile and for the past few months, we've had more than one story just sit on the sprint board for multiple sprints.

After doing some research, I guess the cure for this is to write vertical sliced stories that are very small in scope.

The problem that I see with this is that you can have multiple user stories that are quite similar but limited in scope.

How do you ensure that each dev who works on the story can complete the story without developing tech debt around multiple implementations of the same logic? How do you prevent integration headaches?

For example, if an app is a react/redux app on the front-end with a rails API and relational database.

If the vertical story is "As a user, I want to be able to add counters to my shopping cart." and "As a user I want to be able to remove counters from my shopping cart." And there's no previous logic to handle this on the front or the backend. How do you ensure if you split these tickets that the two devs who work on the ticket don't just waste time doing the same thing but in different ways?

>How do you ensure ... that the two devs ...?

Planning. You said that you work in sprints, do you do sprint planning? Not just a meeting where you decide how many stories will fit into the sprint, but actually planning how the stories will be completed.

For something this trivial, the team should be able to use sprint planning and daily standups to coordinate between themselves to work this out. There are plenty of solutions I can think of, here are just a few. * One dev does front-end for both and the other back-end for both, potentially by pairing together on an initial PR which adds a skeleton of the API so they agree on it. * The second dev waits for the first dev before starting, and re-uses as much as possible. * The two devs pair for both stories and do all of it together. * The team decides one dev will do both stories and the other dev will work on something else.

Think about _why_ you are doing thin vertical slices. You started with large stories which are too big for a single sprint and typically stretch across multiple sprints. The reason this is a problem is that it's hard to plan, and no value is delivered until several sprints later when the story is eventually completed.

Horizontal slices solves the first issue but not the second (nobody is receiving value from just the back-end of a large feature). Vertical slices solve both issues. If your vertical slices are so thin that you can now complete several per sprint and have introduced coordination problems between team members, perhaps they are too thin. You don't need to go overboard, you just need to solve your original problem (stories are too big). Bunching vertical stories together is fine as long as you are still completing the bunch inside the sprint, and delivering value.