The Nokia Test (2): Working Software
The second line in the Nokia Test says: Software must be tested and working by the end of each iteration.
This is the second of three items that confirms the team (project) is “iterative.” There is a series of small tests (within the Nokia Test) if the team is really doing Scrum (in Nokia’s opinion).
Why this second line (element)?
With almost everything in Agile, there are many good answers to that question. I will highlight three.
1. We can get better feedback. Only by having the software tested and working can the Product Owner and the Stakeholders give the best feedback, and we want short, small, fast feedback. “Yes, it’s what I said, but now that I see it, it’s not what I want.” When it works, and they put it together with everything else that is working so far, then they can lift their eyes up from the weeds and see if a real customer product is starting to emerge (form).
OK, so what does it really mean to have working, fully-tested software?
Well, each team must define at some level of detail what “done” means. A company, at a slightly higher level, might also have a standard definition of done (with perhaps some wiggle room for special cases).
That definition of done would typically include (or at least address) things like:
- coded (duh!)
- automated unit tests built, in the configuration management system, run, fully passed
- refactored (anything that needs to be refactored has been: code, design, arch) [Note: Some refactoring might also occur after some things below.]
- put into the integrated build and a new (QA?) environment (the new story does not break other things, etc.)
- automated functional tests built, in the CM system, reviewed by business guys, fully passed per a QA person
- other testing done (more variable by effort, e.g., some performance or exploratory testing)
- business side testing and review (maybe by the Product Owner — full thumbs up)
- fully documented (any docs that need to change because of this story have been changed and reviewed and are perfect)
- no outstanding bugs (or none of any consequence)
If a story passes the above criteria, then a business person (in most projects) can assume a fairly clear and small amount of additional effort to take that story or feature live. This knowledge can be very powerful and give the Product Owner the courage to identify more early releases.
3. Working and fully tested software is necessary to know (meaningfully) the team’s Velocity. (Velocity is really a later element in the Nokia Test, but this line in the test is setting up the team to have a meaningful Velocity.) Velocity is useful in many ways, but I’ll explain it with the family vacation metaphor. When the kids in the back seat ask, “When will we be there?” if I know we are going 60 mph (our Velocity) and it’s 180 miles to go, I can give a pretty accurate answer — good enough to make mission critical decisions like whether to pull over for a potty break. As it turns out, good enough for most real business decisions, and, as it turns out, giving us info with as much quality as we can get.