4 ms·

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

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

throwaway203719 7y ago

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