I honestly believe that having high-energy and high-impact Sprint Reviews truly differentiates high-performance agile teams and organizations. It's very much of a "Show Me the Money" moment for the team. It allows the team to be transparent and demonstrate their results. It allows the organization to provide feedback. And it serves as a progress baseline / milestone so as to measure progress towards established goals. And finally, it should be cause for "celebration".
In many ways, agile delivery is about Earned Value, and EV is demonstrated one sprint at a time.
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.
A coaching colleague of mine approached me with some questions for a university class he was asked to do on Product Ownership. I got the impression the lecture was for a Software Engineering class that was being introduced to Agile Methods in general and the Scrum Product Owner role specifically.
Here are the five questions and my answers:
George Lawton, from the ServiceVirtualizaton.com blog asked me for an interview. He was generally interested in KEYS to agile testing maturity. Something Mary Thorn and I have been “yacking” about for quite some time.
I thought it might be interesting to share his questions and my answers. It will even be more interesting to see “what parts” of my answers make it into his blog ;-)
Stay agile my friends,
Bob.
In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition[1]. In both books I took on the topic of Backlog Grooming.
As it turns out the term “grooming” is losing its luster in the community and terms like maintenance and refinement are replacing it. I believe the latest copy of the Scrum Guide uses the term refinement. So I will try to start using Backlog Refinement consistently throughout this article. That being said, I really, really like the implications of the term grooming.
My friend Lee Copeland [i]asked me the following question:
Bob,
I'm putting together a keynote talk and need some examples --
projects that were successful in the sense that they implemented the requirements, within budget and time BUT didn't return any actual value to the business.
Got anything you can share?
Thanks,
Lee
Introduction
Have you ever entered a Sprint taking on a User Story that you later regretted? For example:
- One that you should have broken down a wee bit more?
- Or one where the team had not a “snowball’s clue” how to technically implement?
- Or one where the value wasn’t clear from a business perspective?
- Or one where the estimate and the reality were not equal?
- Or one that, when you got it “Done”, you weren’t quite sure how to determine that it was done?
I’m guessing, of course you have. I encounter these scenes in teams I’m coaching all the time. And truth be told, it’s not a terrible event. Teams make mistakes…all the time. And they usually learn from them.
If you don’t know, I’ve got some opinions about Scrum, the Product Owner role, Backlogs, and User Stories. I’ve written a book about Product Ownership and I spend a great deal of my time up to my eyeballs in stories and backlogs at various clients.
One of the things that frustrates those clients is that there are very few “prescriptive rules or firm guidance” when it comes writing stories and crafting Product Backlogs; in many ways, it’s more art than science. It’s also a practiced skill that gets better the more you actually do it—of course as a team, which is also true of agile estimation.
No is a very tricky word. I often talk about agile teams needing to “just say No” to various things. For example:
- If their Product Owner expects them to deliver more than their capacity
- If their Boss asked them to deliver faster and it would violate their Definition of Done agreements
- If a Team Member continues to “go it alone” and refuses to collaborate as a team
Then I’m looking for the team to say No. Whenever I bring this up in classes or presentations, I always get pushback. Always. Usually its not based on the situation, but to the word. It seems No is a word that nobody likes using in the workplace.
There’s a wonderful video by Henrik Kniberg where he explores the role of the Scrum Product Owner. In it he makes the point that the most important word that a Product Owner can use is No. That it’s incredibly easy to say – Yes to every request. To pretend that things are always feasible or easy. But that No is important. No implies that trade-off decisions need to be made on the part of the customer or the organizations leadership. That the word leads to thinking, discussion, and decision-making.
