HACKER Q&A
📣 throwaway203719

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?


  👤 clusmore Accepted Answer ✓
>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.


👤 postfacto
Perhaps agile doesn’t actually work (despite the hype) and your team having this quandry is actually your team starting to be awakened to the truth of why agile tends to cripple any project it touches.

Dump agile, write the backend first, in a thick juicy horizontal slice, create a decent json schema document for it that you show to important people at the mandatory demo, and then hand the schema document to the front-end person with the understand you may have iterate on your API a bit as you incorporate their feedback.