
Ask HN: How do you write vertical sliced user stories? - throwaway203719
My team is trying to use agile and for the past few months, we&#x27;ve had more than one story just sit on the sprint board for multiple sprints.<p>After doing some research, I guess the cure for this is to write vertical sliced stories that are very small in scope.<p>The problem that I see with this is that you can have multiple user stories that are quite similar but limited in scope.<p>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?<p>For example, if an app is a react&#x2F;redux app on the front-end with a rails API and relational database.<p>If the vertical story is &quot;As a user, I want to be able to add counters to my shopping cart.&quot; and &quot;As a user I want to be able to remove counters from my shopping cart.&quot;  And there&#x27;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&#x27;t just waste time doing the same thing but in different ways?
======
clusmore
>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.

~~~
throwaway203719
Typically we've left the implementation details to the developer working on
the tickets.

* 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. *

Isn't this essentially just a horizontal slice? So you would subtask this
horizontally but the story itself would be vertical?

~~~
clusmore
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.

------
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.

