Of course it’s going to happen. No matter how good an agile team is, eventually they’ll have a tough sprint and something bad will happen. They’ll miss the work they committed to in the sprint and some of it will need to carryover to the next sprint.
Mike Cohn had this to say about demonstrating that work in the current sprint in his December 10, 2015 newsletter:
A standard rule in sprint reviews is that the team should show only work that has been completed. This rule prevents a team from feeling that they've made more progress than they really have. Additionally, it avoids any risk that attendees leave a review confused about what has really been completed.
And so, teams are told they cannot show slides or partially finished work.
This is a great rule. But, just like my daughter tells me about her curfew, some rules are meant to be broken.
And so I sometimes break the rule about only showing finished work. A sprint review often brings together important stakeholders who are rarely together otherwise. That is a wonderful opportunity to ask them collectively, "What do you think of this screen [or other work] that is in process?"
It would be a shame to forego this opportunity just because of a Scrum rule.
Mike echoed my own advice for teams. But I usually adopt a harsher, no review posture, and Mike’s newsletter forced me to reconsider that advice.
I want to explore several aspects of sprint work that weren’t all covered in his newsletter.
In a recent article on AgileConnection, Allan Kelly wrote the following about the timing of writing acceptance criteria (acceptance tests) for user stories:
The Right Time to Define
I am frequently asked, “When should we write the acceptance criteria?” Sometimes programmers resist giving an effort estimate for a story unless they can see the ACs—sometimes detailed ACs, at that. However, there is little point in POs (and testers) spending time on ACs until stories are about to be scheduled. After all, if ACs take hours to write and the story is not scheduled, their time is wasted.
Also, if ACs are added but then the story doesn’t get scheduled for a year, by that time the story and the ACs may have changed. Because old criteria are in place, it can be easy to overlook these potentially important changes.
This update is from the STP conference I’m attending in Denver the week of November 3, 2014. Software Test Professionals is a conference mostly focused towards testing, so the slant of all of the talks is that lens or perspective. That being said, the agile topics are by definition broader and more whole-team centered.
I just attended a session by Jeff Porter where he was exploring agile practices in a talk entitled: Agile – Where the Rubber Hits the Road.
Now let me start by saying that I liked Jeff’s talk. It was very pragmatic and practical. He simply shared what they were doing at FamilySearch.org. Practitioner reports like this one truly enhance the state of practice in the agile community.
Introduction
There are several terms used for it within agile contexts. Sometimes you hear:
- Done
- Definition-of-Done or DoD
- Done-Ness Criteria
- Acceptance Criteria
- Release Criteria
Sometimes you even hear it repeated, as in: This story isn’t complete until its—“Done…Done…Done”.
Apparently the more “done’s” you have, the more emphasis there is on completeness. Although I don’t think I’ve heard more than four “done” used in a row.
Recently a young engineer stopped me after a class I shared at a national conference and was asking questions. The context in this case was this:
We were talking about the importance of having “dynamic” Sprint Reviews that engaged the organizations stakeholders and customers. How showing “working code” was important for the team to show progress towards their Sprint Goals and commitments.
In this particular case, the client organization was delivering more API level software to their internal customers. They were being asked for system-level functionality in some communications equipment and would implement low-level code to meet the requests. They would expose the User Stories functionality via API calls.
