Story points and the meaning of done

Dan Ackerson at Boost Agile (@boostagile, HT  Craig Brown @brown_note)) posted on what he calls “cross-dysfunctional” development teams.  He focuses on an all-too-common case: developers want to keep working on to new features, but support and QA types want the bugs cleaned up.  IMO, Dan’s team is falling victim to a false choice here:

[Support and QA] don’t care about new user features – they want the bugs fixed. Because the project team only gives points to new features, the support colleagues feel left out and forgotten. Their job is seemingly made harder by our “overlooking” bug fixing. 

The choice isn’t between new features and bugfixes; IMO, the choice is between accepting a new feature only when it’s clean or doing constant rework when a bug-ridden story is called “done”.  How can a development team get “credit” for new feature story points when/if a feature doesn’t perform as designed?  

My take: this is another demonstration of why agile development has to be more disciplined than waterfall, not less.   Dan is on the right track when he suggests that “writing more tests” will get his team on a faster track.   His team should also take one step back and ensure they know what done looks like before writing!

%d bloggers like this: