Designing for unhappy paths
A while back I read an awesome article by Matt Stephens on Level Up Coding about the challenges encountered in sprints when a user story generates a number of additional (unanswered) questions, reducing dev teams’ ability to accurately estimate effort and resulting in v-shaped burn patterns.
Why? Because there wasn’t any upfront work on the unhappy paths.
The solution proposed in that article was for devs and BAs to work on unhappy paths at the beginning of each sprint.
This will certainly fix the problem as it appears in the sprint, but it doesn’t have to be solely the dev team’s responsibility. Just because the devs are the last team to touch a product, doesn’t mean they’re responsible for fixing a rushed or ill-thought-through design process.
Just because the devs are the last team to touch a product, doesn’t mean they’re responsible for fixing your ill-thought-through designs.
