I had a great example of how to negotiate and split stories so they are small, achievable pieces of work without being dependent on each other the other day.
One of the teams I’m working with is just starting trying to build a site that will handle the sharing and collaboration of images for design work. I discussed with them the need to have a log-in/security feature and the need for a comments system for the images. The conversation came around to tagging others is a comment and how to best allow that. The team seemed to be getting stuck on implementing the security first then the comments system so that they could communicate with others. While that’s a nice to have that, the dependency makes it less feasible.
So what I suggested was a story that implemented the security piece, and a separate story that built the comments section, without the tagging. Individually they were small enough to build in their sprint and they were not dependent on each other. We can then add another story in a future sprint that does the tagging. This way the dependency in the sprint is broken, and the future story is part of the iteration of the product.
I really like this example because of a few things:
- Keeps the focus on the core product, what does it NEED to do. ( I like to have 3 things )
- Remove dependencies from the sprint so the team can complete work.
- Allow the product to improve in future iterations.
- Negotiate with the team so they understand the main goals and are involved in the decision.