Wednesday, July 2, 2008

Common Scrum Pitfalls - Splitting stories makes building the quality in hard

I have noticed several scrum teams applying Test-Driven-Development, having stories tested and still not managed to build the quality in (lean principle, remember?). I've asked myself why and here's what I've learned so far.

Let's start from basics. Your team is having 2 weeks sprints. We are in sprint planning and the product owner explains a story that is too big for team to implement in one sprint. Common solution for this is to split the story (to fulfill the INVEST attributes; Independent, Negotiable, Valuable, Estimatable, Small, Testable) so that's what the product owner does. He needs to do it actually several times in order to fit it in to the upcoming sprint.

Fine, team goes and implements the story (test-first) and then demonstrates the story to the product owner. Everybody's happy and next sprint the team continues from other subparts of the original story (that is not visible anywhere - maybe a theme, but that's it).

After three or more sprints we get a bug report from production. User's have discovered a buggy scenario that actually was the original story that was split few sprints back. Each individual test passes in teams integration environment, but we discover that the team did not have test for full scenario (as we split the story and implemented test for INDIVIDUAL stories, but not for the original story).

Lesson learned

When you split the story please still add a task to implement the test for original story with the scope of that story. Add the test to your integration environment and see it passes once the "theme" or "epic story" is done.

Or ... implement kanban instead of scrum - why bother with splitting if you do not need to split :)

Oh, btw about TDD.. Remember this post? Take a look at the following video - great conversation between great names :)