In Integrum Chris talks to Roy van de Water and Drew LeSeur of Integrum about running Agile Learning Labs as a transparent company with a radical compensation plan, and about writing The Elements of Scrum using scrum, and how our new book, Scrum: A Breathtakingly Brief and Agile Introduction is an iteration of our first one.
Roy and Drew ask some excellent and hard questions, so tune in and give a listen!
If you are at the 2012 Atlanta Scrum Gathering, you got a copy of The Elements of Scrum by Chris Sims and yours truly in your conference goody bag, as we are proud sponsors of this year’s event. If you’d like Chris to sign your copy, he’ll be doing so at 12:30 pm on Tuesday in the Heritage Room. And I promise: if you bring along three rubber chickens, he will juggle them!
What, you say you don’t yet have a copy of The Elements of Scrum and are consumed with envy? Easily solved! Take one of our CSM or CSPO classes and you’ll get one, or if you just can’t wait, buy yourself a copy here on Amazon. Makes a great Mother’s Day gift! Just kidding. That would be, like, the worst Mother’s Day gift of all time. If you need a Mother’s Day gift, buy her a copy of my mom Ricki Grady’s book, BeBop Garden instead.
We published this little book very quietly last week, and without so much as a tweet it has already become the #2 bestselling kindle book on software project management, right behind our other book, The Elements of Scrum. The response to Elements has been tremendous over the past year, and a lot of people have singled it out as a refreshingly brief and readable way to get the goods on Scrum. But at 180 pages, you could say it’s only relatively brief.
What if you are sending a team off to scrum training next week and want to give them a taste to fire them up? Or let’s say you are a scrum evangelist at your company and can only count on 15 minutes of your CEO’s attention to spark her interest? Or maybe you’re a scrum master and you just want your husband to learn enough about what you do that he doesn’t glaze over at the dinner table….
In those cases, you’ll need something not just refreshingly brief, but breathtakingly brief. Which is why we took some of the most salient material from The Elements of Scrum and retooled and repuropsed it into a pocket-sized, highly consumable little volume that is cute enough to send to your granny as a birthday card, but smart and sophisticated enough to slip to your CEO or HR director. Meet Scrum: A Breathtakingly Brief and Agile Introduction by Chris Sims & Hillary Louise Johnson. You can buy it on Amazon in paperback for $9.95, or get the Kindle version this very minute for a mere 99 cents.
Late last year, Agile Learning Labs began incubating a new venture, Dymaxicon, to explore the publishing space for agile-themed books, and beyond. This Saturday, August 20th, we’ll be celebrating the success of our first two titles, The Elements of Scrum by Chris Sims and Hillary Louise Johnson, and The Bad Mother, a novel by Nancy Rommelmann. We’ll also be introducing a rash of new titles.
For an introduction to what agile publishing is all about, check out what the Huffington Post has to say about us. As you may or may not know, few business models are as top-down and old-school as traditional publishing. It’s also, as you may have noticed, an industry in gross, spectacular decline of late (Rupert Murdoch, anyone?). So this seemed like a great space in which to start rolling out agile methods, especially as one of our founding team members, Hillary Johnson, hails from that world, having been at various times a novelist, magazine writer and newspaper editor.
Dymaxicon is in the midst of launching a whole new spate of titles, including a video series and several new fiction titles. Many of our authors will be present on Saturday to sign books and answer questions, so come join us for wine, food and cutting-edge literature. More details on the evening’s line-up after the jump.
Saturday, August 20, 2011
6 to 8 pm
Internos Wine Cafe
3240 Geary Street, San Francisco
Continue reading
Come help us celebrate the launch of Dymaxicon – a new kind of publishing house brought to you by Agile Learning Labs.
Saturday, August 20, 2011, 6 to 8 pm
Internos Wine Bar
3240 Geary Street, San Francisco
Raise a glass and toast a new, agile way of producing books, videos and media. Join Chris Sims and Hillary Louise Johnson to celebrate the success of their book, The Elements of Scrum. Come meet some of our dynamic authors whose books and videos have recently gone to press:
The wine will be flowing and the canapés will be on the house. You’ll also get a chance to sample Dymaxicon’s diverse offerings: we’ll be showing highlights from Jeff McKenna’s video series, Conscious Software Development, and Nancy Rommelmann will be reading from The Bad Mother. You can buy a copy of The Elements of Scrum, or bring yours in to have it signed by the authors. We’ll also be giving away bound galleys for upcoming titles, so you might just snag a collector’s item.
To learn more about these and other authors, and to find out what agile publishing is all about, visit www.dymaxicon.com. To see our video series and trailers for recent and upcoming titles, visit our YouTube channel at www.youtube.com/dymaxicon.
Chris is at Agile 2011 in Salt Lake City today, and part of prepping for his Tuesday session on Agile Requirements: User Stories and Beyond included reviewing the following chapter from The Elements of Scrum, by Chris Sims & Hillary Louise Johnson (c’est moi). Here is the text of that chapter in its entirety:
User Stories
Computers make it easier to do a lot of things, but most of the things they make it easier to do don’t need to be done.
~ Andy Rooney
User stories are the building blocks of the product backlog. Combined with conversations and acceptance criteria, they are an efficient and effective way for product owners to provide requirements to the team. Notice how these aren’t called “product manager stories” or “system architect stories”? We call them user stories to keep the focus where it belongs—on the things real people are going to need the software to do for them.
User stories are often written out by hand on index cards, although some teams do opt to use software tools to record them. Many teams use one particularly popular format for a user story; it’s not the only way to write a user story, but it is a good way. Here’s the template:
As a
I want
So that
This format for expressing requirements captures a lot of information in only a few words.
The first line:
As a
tells us who wants the functionality. Remember, we build software systems and products for people!
The second line:
I want
tells us what the desired functionality is.
Finally, the last line:
So that
tells us why this user wants this functionality. Having stated who wants what, and why, here is an example user story in this format:
As a member of the Madonna Fan Club,
I want to order concert tickets by phone before they go on sale to the general public,
So that I can get great seats and feel special.
Armed with a sense of who our somewhat geriatric users are and what they value, we can create a phone ordering system that will give them a lot of value. We can have Madonna record a special greeting: “It means a lot to me that you are a member of the Madonna Fan Club. As my way of saying thank you, I’m holding a block of the best seats just for you…”
Traditional requirements often indicate the “what” while leaving out the “who” and the “why.”
But maybe Madonna’s fan base consists equally of old-timers and impressionable 12-year-olds who think she is retro-fabulous.
The Madonna team might push back, asking their product owner if a web-based system might not work just as well for both audiences. Perhaps the team could deliver such a system in half the time it would take to build the phone-based system.
As good as this user story template is, and we think it’s pretty good, it’s not the One True Way to write user stories. Any format that leads to a shared understanding, and facilitates the production of valuable software, is fine. Remember, it’s not a religion; it’s a tool you can use to help your team succeed.
Variations on the Theme
The above user story format puts the focus on the user; they are listed first. Some teams prefer to move the focus to the user’s goal or the value, so they change the order around.
Goal-focused
In order to
As a
I want
Value-focused
In order to
As a
I want
A User Story is a Ticket to a Conversation
User stories are not complete requirements or specifications; they are placeholders. They contain enough information to remind the team that there is something there to be done, but we intentionally don’t go into a lot of elaborate detail… until it’s needed.
When the time comes to elaborate on the user story, we prefer to do it in the form of a conversation between the team members involved. The goal of the conversation is to come to a common understanding of what the story is about, and exactly what needs to be done.
A live conversation is a much more efficient way to reach this goal than relying on written documentation. There is more information flowing, or if you prefer, the connection has much higher bandwidth.
Acceptance Criteria Make it Real
When you get to the point in your conversation where everyone thinks they have a common understanding of the user story, it’s time to write acceptance criteria. Generate a list of pass/fail tests, written in plain English, such that if they all pass, then everyone involved in the conversation would agree that the story is implemented as intended. Acceptance criteria answer the question: “How will we know when it does what it should do?”
It is useful for every user story to have acceptance criteria written by the product owner. For stories that the team will be working on soon, this sprint or the next, these criteria should be fine-grained and thoroughly understood:
customer’s email address is captured
Ideally, the team should be able to write automated tests based on the acceptance criteria, even before the functionality is implemented. For stories that are lower in the backlog, and may not be implemented soon, the acceptance criteria can be less precise; a few bullet points may suffice. Part of the work of grooming the backlog is to evolve the acceptance criteria.
Here’s how to recognize an expert product owner: they have all of the acceptance criteria defined and agreed to by the team before the start of the sprint, and these don’t change during the sprint. Be warned! This is not a trivial goal, and it usually takes some time before the product owner, and the rest of the team, learn what it takes to reach it.
Putting it all together
The user story, the conversation, and the acceptance criteria combine to form a complete requirements specification. The user story allows us to quickly, yet richly, capture ideas. In conversation we can elaborate and come to a common and actionable understanding of exactly what is needed. Finally, we capture our common understanding in acceptance criteria that are specific and testable.
©2011 Chris Sims, Hillary Louise Johnson and Agile Learning Labs. All rights reserved.
An extraordinary agilist and friend, Harold Shinsato, captured this video at the release party for our new book “The Elements of Scrum.” My favorite moment is when Hillary explains why they chose not to capitalize scrum and how agile is not a noun. Enjoy!
The Elements of Scrum – Book Release Party from Harold Shinsato on Vimeo.
Chris and I just finished the first draft of our book, The Elements of Scrum, and will be publishing a “beta” paperback by February, just in time for Agile Open Northwest, of which we are a proud sponsor.
One of the biggest remaining debates we’re having is over capitalization. After great deliberation, we’ve chosen not to use agile as a noun in the book (e.g., “In Agile we do it this way…” or “Agile is about…”). In my humble writer’s opinion, when we “thingify” agile by hardening it into a proper noun, the term loses a little bit of it of its transformational power. We want help the word to remain an adjective, a powerful, dynamic descriptor, so we’ve chosen not to nounify it. We’ve also decided not to capitalize it.
But what about scrum? Or Scrum? Scrum is already a noun, but is it a proper noun requiring capitalization? And how about “ScrumMaster” vs “scrum master”? Is it ever kosher to un-couple the camel?
Chris has argued in favor of capitalizing Scrum, saying that “Scrum” is to “agile” as “Chevrolet” is to “car.” I’m not so sure. Chevrolet is a proper noun because it is the name of a brand, and thus a proper noun. I think “scrum” is to “agile” as “existentialism” is to “philosophy.” So I vote for not capitalizing it. The jury is still out, and I’m willing to be persuaded.
And then, what to do with ScrumMaster? I am inclined to leave “ScrumMaster” to the Scrum Alliance, which owns the trademark for Certified ScrumMaster. Ken Schwaber used to hold a trademark for the word “Scrum,” but that application is now listed as “dead” according to the USPTO, and I have to credit Schwaber for thinking twice about that one—it seems the generic term ought not to be owned outright by him or anyone else. Besides, think about how much laugher there was when Donald Trump trademarking the phrase “You’re fired!”
Personally, I’d prefer to promote the use of the more modest “scrum master” when talking about someone who performs that role for a scrum team, certified or not. I’m not by any means anti-certification, by the way—in fact I’m one of those dorks who has their ScrumMaster certificate on their office wall because I think it’s kinda cool.
But–and this is key–while I am a Certified ScrumMaster, I am not a scrum master, because I have never served in that capacity on a scrum team, nor would I feel qualified to do so.
I think it very possible that there are lots of people out there who, conversely, consider themselves scrum masters, and not ScrumMasters. We had a student in our last Certified ScrumMaster class who was actually a member of the first scrum team—he found that he needed to be certified for his consulting business, even though no one could possibly dispute his standing as not only a scrum master, but a master of scrum. (He wasn’t at all bitter about it, by the way, but viewed the irony as merely a side effect of scrum’s evolution.)
Wikipedia’s style guide appears to agree with my approach, as does Grammar Girl, who expresses some disdain for what she calls “pride capitals.” I’ll be curious to see what the new edition of the Chicago Manual of Style says once I get my hands on a copy!
What do you think? Is there room in the young discipline of scrum (or Scrum) for the designation scrum master?