Estimating for a good backlog and release planning

A developer recently explained to me that “agile means that we plan this sprint and know our backlog; whenever we get enough done on the backlog for it to be interesting, we release it, but we don’t ever plan more than the current sprint.”  I didn’t choose to engage in an argument at the time; I just wanted to see his position.  In my own work, I observed that the team was not achieving the definition of “done” on half of the stories in the two-week sprint.  More interestingly, there was not even a common understanding of the goal of the sprint or the user value that would be achieved.

As we started having discussions about this, I realized that there were a few things missing:

  • We had a very loose concept of a release plan, and the set of features (let’s call them epics) that would make up a useful release in the market.
  • We had no estimates, and therefore no shared understanding, for the backlog. As we groomed the backlog to focus on only the interesting items for this release, the product owner team came to a realization that we didn’t have a shared understanding of the backlog items, and were uncovering this shared understanding during the sprint. I think I may have said “one of the cores of scrum is for the team to have a shared understanding of the requirement and the solution.”

Next week we’re going to do an estimating process, first for our next sprint which is just starting, and then for enough of a backlog for the next sprint. (We have a tradeshow coming up soon, so we have two sprints to deliver demonstrable value.) It’s not optimal timing within the sprint, but should get us to focus on our company objectives and have a shared understanding of what we can deliver.

Mike, at LeadingAgile, wrote a great post about estimating, titled “the real reason that we estimate.” I’d like to bring over a few paragraphs of his and then reflect a bit.

You see… estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, its almost never an estimating problem, it’s a shared understanding problem. If you can get to the bottom of your shared understanding problem, you will fix your estimation problem.

The product owner needs to represent the problem well. The product owner team, a great concept of Mike’s, will work together to make appropriately bite-size stories for the backlog. The team will then estimate those. I’ll give my thoughts on product owners, product owner teams, who can create a story, and who is responsible for the backlog in the future.

Giving up estimating is basically giving up being able to give the business any idea of what they are going to get or when they are going to get it… even at a high level. My take is that we can’t give up estimating, we need to get better at estimating, but that means that we need to get better at creating shared understanding. It’s my opinion that creating shared understanding is the main reason we estimate. It’s not so much the number that matters… it’s the shared understanding that matters. If we are estimating without creating shared understanding, we are missing out on the value, and the estimates will always be poor.

One of the biggest things we need is some way to estimate size for epics (and stories as they get closer) and the business value of the epics. Then do release planning to determine roughly what will fit in, and refine as we go. But we’re doing this with some idea of capacity and time frame.

Scrum 101, thanks to Mike Cohn

Scrum Overview, from product backlog to the sprint deliverable

Scrum overview

As you can see in these posts, I’ve been refreshing my detailed knowledge of Scrum, which came both from practice and from the 280 Group’s Agile Product Management Excellence class. As I was doing this, I realized that the methodology I had learned, and the scrum masters I had worked with were, respectively, created and trained by Mike Cohn. I already had two books from Mike Cohn’s series, and had just ordered Essential Scrum: A Practical Guide to the Most Popular Agile Process; I heartily recommend the book. Since people make this information available on the web today, in summary form, I found an overview of Scrum on the Mountain Goat Software website. I recommend that you read all of the topics. An outline of the topics follow. Of course, there are also any number of articles on the Mountain Goat Software site.

But, if youwant the overview, go to the slide deck, or read the set of pages linked to below. They will give you an overview of the entire process.

Topics in Scrum

Sprint Planning: Hours or Points

SprintPlanning1I’ve been  practicing agile for years, but always with the lead of a strong scrum master or one in training with a good mentor.  There are things that I just simply assumed were “the way things were done.”   As a product manager  and the product owner, my main concerns were that there was a well groomed backlog, joint understanding of the stories and the overall team velocity.  I left the rest to the scrum master and the team, and I cared about the burndown.

Besides  Explaining Scrum in less than 120 seconds from the previous post, I also found a Simple Cheat Sheet to Sprint Planning Meeting. That post doesn’t talk much about the units of capacity, but I’d always seen it as hours. You then estimate hours available, counting vacations and known reasons for being unavailable beyond the work of the sprint.

SprintPlanning2What I found was that the team was estimating tasks in story points, and working to make sure that the sum of the points for the tasks matched the number of points for the overall story. This led to large tasks and the lack of numerically measurable and perceptible progress. There was no burndown or burnup chart.

Mike Cohn describes this well in his posts “Why I Don’t Use Story Points for Sprint Planning” and in his description of the sprint backlog. This page and others in the series do a great job with the concepts of agile. Mike also has a Powerpoint presentation  Introduction to Scrum available on Mountain Goat Software’s site. I especially recommend slide 24 on sprint planning and slide 30-39 on the product and sprint backlog. I’ve put thumbnails of these slides on the right. Thank you, Mike, for your very clear presentations, graphics and examples of Scrum.

I now know why the recommendation is to move from points to hours in sprint planning. The process always needs to be concrete, and mapping the work to the people and their schedules and availability is key.

Addendum: People pointed out a blog by Jeff Sutherland on this topic, titled “Story Points: Why are they better than hours.”  Any blog entry with 75 comments has got to be interesting. In the comments, Jeff points out three ways that a team can work

  1. Backlog in story point and no tasking (hyperproductive teams)
  2. Backlog in story points and tasks in story points (best current practice as teams are getting better)
  3. Backlog in story points and tasks in hours (the old way)

In other words, you start at #3 and work up. I’d also believe that the effectiveness of #1 is proportional to the size of the stories (smaller stories makes this more possible).

Learning Agile: Bruce Feiler discusses approachable Agile in the family


Bruce gives an overview of Agile, starting about three minutes into this video. While many talks on agile get caught up in the details of implementation, this video makes the tenets of agile approachable.  I suggest that you watch it, and feel free to share it with your family so that they can understand what you do at work.  My kids are a bit too old (Claire, 28 and Peter, 30) to apply this at home, so I’ve got to apply the principles at work.

If you want a deeper view of Scrum, look at the Scrum Guide, available on the web and just recently revised. There are a large number of videos on Scrum on Youtube. One, Explaining Scrum in less than 120 seconds is a great introduction.  A more detailed view and history can be found, from Ken Schwaber in 2006, as a Google Tech Talk; the video runs about an hour.

Sweet Home Chicago. After 20 years in Silicon Valley

I’ve identified myself with Datalogics for decades.  It’s where I got my start as a software developer just out of school, just starting a new product line for the PDP-11, where we grew the business to a $17M annual revenue company until we were acquired by Frame as SGML experts, and then a long journey to California, Adobe, eBooks, PDF and server software.  I’ve been working with Datalogics as a consultant since the summer of 2012, and just signed on as Director of Product Management to bring some new business ideas to market, as well as refining the product process. I started back there on a full-time basis on July 29.

I picked the title “Sweet Home Chicago” for this post, little realizing the subtleties. In 1995, my theme song was Burt Bacharach’s “Do you know the way to San Jose,” as much as I dislike Burt. Coming back now, while still living in California, made me think of “Sweet Home Chicago” as popularized by the Blues Brothers.  A quick read of Wikipedia shows the tension between California and Chicago, with the lines
“But I’m cryin’ hey baby, Honey don’t you want to go
Back to the land of California, To my sweet home Chicago.”

I’m back, looking to apply agile methodologies, to the extent that they make sense, and the best of product and customer understanding, to make new ideas and profitable ventures blossom at Datalogics. And, even though I’ve “done agile” at multiple places in the past, beginning with Adobe, this will be my first time bringing it in (along with engineering) rather than having it imposed. I’ll be blogging about my experiences and sharing pearls of wisdom from others with the team as we go down this agile journey together.

This blog has been sitting around in a semi-finished state since November of last year. It’s not perfect now, but I’ll work to make it better over the coming weeks. At some point, you just need to get it out there, and this agile product management thread seems like the best reason for this.

Errors 101: ReadWriteWeb’s 12 deadly grammatical errors startups must avoid

There was a great article yesterday that Michelle Turner pointed out on Facebook. This 12 Deadly Grammatical Errors Startups Must Avoid blog gives some of the most common simple errors. My favorites are “its or it’s” (1) “you’re or your” (6) and “flush out an idea” (9).
It’s painful to see brilliant people create blog posts with grammar so confusing that you have to work at reading the post to bring out the meaning. It’s worthwhile when you reach the end, but it would be so much more effective if one could easily read the content.

I also take issue with his “this does not apply to non-native English speakers.” My experience has been that people who have learned English as a second language are better at English usage, as they pay more attention to the rules. My advice to non-native speakers is to keep using our language and feel free to point out errors made by native speakers, as long as you do it in a non-judgmental way.

The New Yorker lifts me up on the contraception debate, but lets me down on hyphens

I love the New Yorker magazine and its writers. It is the one magazine that I am sure to read every week; it is always written and edited well. That’s why the lead article in the March 19 edition, Taking Control, in “The Talk of the Town” surprised me. [Before I digress into grammar, I will say that the editorial was spot-on. My daughter of 27 years is living in our house for a short while, and Ann and I hear the moral outrage from Claire and her friends on a regular basis. I can only hope that this outrage is widespread in the polls and has an impact on Congress and the state legislatures on election day 2012. Those contests may matter more than the presidential race if we want to break the logjam in Washington and roll back the reactionary agenda in the states. I do look forward to the time when contraception and transvaginal ultrasound are not dinner-table conversation.]
Two of my “favorite” errors appeared in this article. It seems that the writer is in the younger generation which has a slightly different perspective on the English language and grammar.

The first error is that the Latin phrase ad hominem is hyphenated. It’s not supposed to be, as I noted in a recent blog on foreign phrases and hyphenation. New Yorker editorial review has caught this in the past. Just do a Google search on “ad hominem site:newyorker.com” and you’ll see that this was a deviation from the common practice and editorial guidelines of the magazine.

The second error is that “teenager” is presented as a hyphenated word, “teen-ager.” It occurs in the second paragraph before the end of the article, in the phrase “to become pregnant as teen-agers.” Every dictionary I searched has this as a compound word, not hyphenated.

Margaret Talbot’s content is always wonderful and appreciated; it is only with great fear and trepidation that I question an acclaimed writer. However, I am sure that I am correct. New [incorrect] uses of the English language have been appearing consistently in technical presentations in Silicon Valley. But this is the first time I have seen them spill over into mainstream publications.

How to abuse a foreign language with a simple hyphen, starting with Latin

Large organizations develop their own dialects. One dialect that existed at my previous employer, Adobe, was the use of a hyphen to connect words within Latin phrases. The most common instance of this was ad hoc, which sprung up in hyphenated form, ad-hoc, in many presentations. This problem is more widespread than just one company. If you would like to see this in a Google search, try these searches for “ad-hoc“, “ad-hoc mode” or ‘“ad-hoc” site:adobe.com‘. [To Adobe's credit, most of the hyphenated use of ad hoc is in the forums, where editorial correctness is not the main issue.] You can see that “everyone is doing it,” but, as my mother used to say, that doesn’t make it right. The basic rule is that foreign language phrases, such as those below, are used without hyphens. See Grammatically Correct in Google Books for more detail on this. But it makes it clear that one should “note in particular that Latin phrases never take hyphens.” The Chicago Manual of Style suggests that “foreign words and phrases familiar to most readers and listed in Webster’s should appear in roman (not italics) if used in an English context.” The option to hyphen the words does not appear in the manual at all.

A short list of these common Latin phrases are

Wikipedia has a long categorical list of Latin phrases in case you are curious.

Let’s respect foreign languages and use their phrases correctly.  Even the dead ones.

Grammar Girl delivers a podcast to assist improvement-focused but potentially snarky commenters

I’ll admit it. I have Grammar Girl on my podcast list. I decided to listen to it to help improve my grammar and spelling, as it can be poor at times. The fact that my son was a journalism major in college and is now a high school English teacher-in-waiting also caused me to want to stay a step ahead of his corrections and to learn a bit of theory behind the grammar.
This blog started as a way to raise awareness of the errors that I see on a daily basis. One of the issues is that pointing out errors, especially in long-lived public documents or presentations, can be as socially difficult as pointing out embarrassing items such as an unzipped fly or a major bit of food lodged in a stranger’s front teeth.

I wrestle with this whenever I point issues out to people. I hope that these are appreciated, as I believe that we should all be focused on continuous improvement; most people don’t even know when they have been habitually incorrect. And I appreciate every comment that I receive from others.

Please take a look at the transcript of the podcast or listen on your own; she has multiple links on the webpage. And you may want to join me in gently pointing out issues to people when it is appropriate.

Creative Customer Engagement that Delights

I met a new and fascinating person through LinkedIn this week. He works for a major telecommunications supplier and is focused on customer experience. At one point, the discussion turned to creative techniques to reach customers. We each shared an example that stuck us as truly creative ways to deliver a message. These happened a few years ago, so they faded from memory a bit. That conversation brought them both back to each of us as we shared. It’s worthwhile to raise awareness of them again, as they are both truly creative methods to educate and persuade.

Photoshop: Have you listened to dry tutorials or evangelistic videos when trying to learn tools like Photoshop? There is an award-winning video series called You suck at Photoshop, launched in 2008. It is hilarious. The key item is that it introduces concepts in Photoshop in a very digestible form and shows plausible use cases. The videos do all this in an incredibly humorous, albeit politically incorrect, fashion. I have two favorite episodes. The first is cloning techniques as he retouches a photo to remove a wedding ring. The second is paths and masks as a wedding ring is prepared for auction. Almost everyone I know who has watched these videos has learned new functionality from it.
Google Chrome: Chrome launched in 2008. But it was the way that it launched that was most interesting: they described the architecture of a browser in a comic book. The comic went viral as it explained complex technology in a compelling and engaging fashion. The author’s story and links within it tell much more.We all aspire to deliver information and reach our audience. It’s difficult to cut through the clutter and noise of out everyday lives. These two efforts certainly achieved that, even if “You suck” was not a vendor-driven effort.

I started this post a few days ago, but have since discovered a new book that talks about little things that make a significant difference with customers. The book is “What’s Your Purple Goldfish?“, with its associated website and blog. The first line of the book description is “How do you stand out in a sea of sameness?”. The two examples above certainly broke through the barrier of sameness to stand out.

I’m going to listen to his seminar next week, buy the book and consider how to stand out in the future.