Projects, Projects…..

I thought I should follow up on my previous post for my two readers. We recently completed a very successful sprint with a very predictable burndown and much higher burn-rate. How, you ask? Tiny stories. We asked that if a story looked like it was going to take more then a third of the sprint, break it up. In most cases we had stories that took less then a week. As a result, we were able to focus on getting these small manageable chunks to “done” throughout the sprint. It kept QA and Doc very engaged from day one and gave the Product Owner and upper management much more confidence in being able to commit to the business on our ship date.

So, here’s the real deal. As with most things in Scrum adoption, it was a mindset problem. The problem before was that we were looking at entire features as stories. We were trying to figure out how to get that feature done within a sprint and making statements like “that could never be done in 30 days”, “why don’t we go to 90 day sprints” or even worse “Let’s have a design sprint, followed by a dev sprint, followed by a test sprint” That would be fine, but only if we want to go back to waterfall in every other way as well.

What we did this sprint is look for logical thin slices of work through a feature. What is the smallest thing we could possibly do to give our product owner and our customers some value in this sprint. Those slices became our stories. Some combination of those stories become a feature. This gives the product owner the chance to be able to decide when he has enough of that feature to be able to ship. Out of the 20 thin slices for feature X, 5 might be mandatory, another 5 might be really nice and another 10 could be completely optional.

Find those slices, and prioritize those, and you will see the impact immediately. Encourage your teams to not just push back on the product owner, but help with the story development to get thin slice stories that make sense to the team.