Keywords: enabling specification, definition of done, empirical process, Scrum, acceptance criteria
Abstract: This article explores how to achieve the productivity benefits of an upfront enabling specification, given the reality that Scrum is an empirical process where emergent understanding of the story under development is inherent.
I love reading the walls of team rooms. One team had a poster that read “The old guys have all the money.” This was a reminder to the web team, staffed with youthful developers, to use large enough fonts and appropriate color schemes so that the most important segment of their target audience could actually read and use their web application without having to set the browser magnification at 150%.
Another team used the saying: “It’s not over till the fat lady sings” to remind each other that no matter how well they think they have satisfied the written acceptance criteria, they are not done with a story until the PO says they are done with it. Done is not some arbitrary state of a backlog item. When an item is “Done” users can take advantage of the new functionality and give meaningful user feedback. There is no sense in calling an item done unless from all points of view, including the Product Owner’s (PO), it is potentially shippable. Unfortunately, teams who adopt this philosophy to the extreme often face issues with erratic velocity and poor team morale. In my experience it is not uncommon for teams to struggle with how to deal with a PO’s emerging understanding of a story when faced with an actual implementation. I’ll illustrate with a couple of anecdotes from real recent projects.