Charles Myers

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 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

• Overview
• Daily Scrum
• Product Backlog
• Product Backlog Example
• Product Owner
• Release Burndown
• ScrumMaster
• ScrumMaster Requirements
• Scrum Team
• Sprint Backlog
• Sprint Planning Meeting
• Sprint Retrospective
• Sprint Review Meeting
• Task Boards
• Scrum Illustrations and Wallpapers
• Alternative Burndown Chart
• A Reusable Scrum Presentation

I’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.

What 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).

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.

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.