AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant...

22
AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are at the end of 2013 and planning for 2014, estimation always is a challenging topic in software development work, but is particularly more important at this time of the year, as you’re planning a budget and resources for 2014. Many of you are, I know. So we thought we’ll take this topic today, and explore a little deeper how to do a proper job of estimation, and it’s a real challenge, we find. We’ve been doing Agile development wor k with our clients for a number of years, and we often find between the two extremes of executives needing really precise budgets and estimates for their planning, versus an engineering team and engineering leader, who will often take the viewpoint that software is done when it is done. It is very difficult to estimate when it is done, so we’ve got to strike the right balance. I’m glad to have an excellent speaker, Lee. I’m going to introduce him in a minute. That’s the topic we’ll cover today, which is Agile estimation. By way of mechanics, we will have roughly 45 minutes or so of the presentation here with this topic, and then we’ll take some questions as they need to be taken along the way. The remaining questions, we’ll take them at the end, and after the Webinar is done today, we will make the Webinar documents, as well as the recording, available to the people registered and are attending. With that, let me introduce the speaker. I’m delighted to have Lee He’s an experienced professional with a broad range of roles and responsibilities he has played in his career so far. He’s currently one of the few certified Scrum trainers that are around worldwide. He’s also a project management professional, and a PMI-certified Agile certified practitioner. His experience ranges from hands-on Web development, QA work, automated testing and test development, product management role, project management roles, ScrumMaster; he has been in pretty much every role you can think of in and around software development, so I’m glad to have him cover this topic with us. With that, I’ll turn it over to you, Lee. Lee: Thank you very much. I appreciate it. Once again, I want to re-emphasize, good morning or good afternoon, based on where you are. It’s a pleasure for me to be here today, and I want to thank Synerzip for giving me the opportunity to be here with you today. First and foremost, I want to thank each of you. I realize that your time is very precious, and taking an hour out of your time, often at some point during the work day, is really a sacrifice for you. I realize that this topic is incredibly urgent, and I want to make sure that we allow enough time for a reasonable presentation, but also allow enough time for you to feel like you have your questions answered. So with no further ado, as was discussed, I am Lee Henson. I’m the founder of AgileDad. Whether you come from an Agile background, a traditional project management background … whether you’re doing RUP or Lean or Kanban or Scrum … this presentation is going to apply

Transcript of AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant...

Page 1: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 1 -

Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are at the end of 2013 and planning for 2014, estimation always is a challenging topic in software development work, but is particularly more important at this time of the year, as you’re planning a budget and resources for 2014. Many of you are, I know.

So we thought we’ll take this topic today, and explore a little deeper how to do a proper job of estimation, and it’s a real challenge, we find. We’ve been doing Agile development work with our clients for a number of years, and we often find between the two extremes of executives needing really precise budgets and estimates for their planning, versus an engineering team and engineering leader, who will often take the viewpoint that software is done when it is done. It is very difficult to estimate when it is done, so we’ve got to strike the right balance. I’m glad to have an excellent speaker, Lee. I’m going to introduce him in a minute.

That’s the topic we’ll cover today, which is Agile estimation. By way of mechanics, we will have roughly 45 minutes or so of the presentation here with this topic, and then we’ll take some questions as they need to be taken along the way. The remaining questions, we’ll take them at the end, and after the Webinar is done today, we will make the Webinar documents, as well as the recording, available to the people registered and are attending.

With that, let me introduce the speaker. I’m delighted to have Lee He’s an experienced professional with a broad range of roles and responsibilities he has played in his career so far. He’s currently one of the few certified Scrum trainers that are around worldwide. He’s also a project management professional, and a PMI-certified Agile certified practitioner. His experience ranges from hands-on Web development, QA work, automated testing and test development, product management role, project management roles, ScrumMaster; he has been in pretty much every role you can think of in and around software development, so I’m glad to have him cover this topic with us.

With that, I’ll turn it over to you, Lee.

Lee: Thank you very much. I appreciate it. Once again, I want to re-emphasize, good morning or good afternoon, based on where you are. It’s a pleasure for me to be here today, and I want to thank Synerzip for giving me the opportunity to be here with you today. First and foremost, I want to thank each of you. I realize that your time is very precious, and taking an hour out of your time, often at some point during the work day, is really a sacrifice for you. I realize that this topic is incredibly urgent, and I want to make sure that we allow enough time for a reasonable presentation, but also allow enough time for you to feel like you have your questions answered.

So with no further ado, as was discussed, I am Lee Henson. I’m the founder of AgileDad. Whether you come from an Agile background, a traditional project management background … whether you’re doing RUP or Lean or Kanban or Scrum … this presentation is going to apply

Page 2: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 2 -

across the board to all of you, no matter what walk of life you’re from; whether it’s software, hardware, financial, insurance, construction, et cetera. It doesn’t matter where you are or what you’re doing. This topic is really one that hits the nerve center, if you will, across all these different venues.

Just so you can put a face with the voice, that is me. I’m one of 144 certified Scrum trainers worldwide. I’ve been doing this now for about 15 years or so. I was personally trained and mentored by Ken Schwaber. In addition, when I’m not doing these type of presentations, or out doing executive coaching, I do motivational speaking as well, and help organizations bring their teams through to a full Agile implementation.

One of the neat facts that I’ll throw out there, I’ve actually had the experience to participate in premiere coaching at 41 of the Fortune 100 companies. If any of you out there are from those companies, I’m excited to have you, and I really do appreciate your time.

Our objectives; what are we trying to do today? I think it’s threefold. Whenever you talk to a chief executive, or you talk to an executive officer with “C” in the beginning of their title … they always have the same three questions. What am I going to get? When am I going to get it, and how much is it going to cost? In reality, what we’ve learned … what it all boils down to … is that how you get there isn’t necessarily as important to them, as that you get there. My goal or objective for this session is to help you better understand estimation, and look at it more from an elementary point of view.

I have the children here on a slide; I want you to look at it more from a beginning point of view, because I think if we rest and start doing things a little better early on, it’s going to help us achieve that objective. I don’t have very much high-level overview, but I did want to throw this one piece out there, because I think it’s really interesting when you look at the statistics. So, a couple of different third party non-related research organizations went in and did some research about the actual process. And in a traditional waterfall model, roughly 17 percent – 17 percent of our projects come in on schedule. Of those 17 percent that come in on schedule, they come in at about 189 percent of costs. And then when we finally do deliver those features, only 20 percent of what we intended to build is actually used by our end consumer.

Obviously, you can see there’s a great level of concern here. That’s not to say that the Waterfall process is completely broken, because I have seen implementations of the waterfall process that have worked successfully. What it is saying is that Agile needed to find a better way. This is the part where you really need to pay attention, because this is where you need to be. When it comes to cost, I’m going to have an opportunity to sit before you today and say that I’ve worked on hundreds, if not thousands, of Agile projects, and I’ve never gone over cost.

In addition, when it comes to schedule, I’m going to be an advocate and say in the Agile world, that we need to have a deadline. We should have a date. Someone should say, “Hey, this is

Page 3: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 3 -

when we need something delivered by.” The question then becomes, what high-quality features can we reasonably deliver without exceeding that cost, and staying within the time line that’s present?

This is one of the pieces of my coaching packet that I often leave behind when I visit with executives. It’s more of an executive project dashboard, but what I like for people to do is, I like to have an internal sort of working service level agreement between the executives and the teams that are actually going to be doing the work; between the executives and the product owners. What I like to see is, very early on in the process … in other words, right after road mapping … we’re going to walk through the five steps with you. Right after road mapping, I want to get an idea of, “OK, Mr. Executive, as your Agile coach, here are 30 items that you proposed that we do.” These might be at an epic level some … some may be at a regular backlog item level.

Of these 30, we just know that the last 10 are just off the table; it’s unreasonable. We don’t have the people, we don’t have the time, we don’t have the budget to finish those 10. Of these 20 that remain, what’s interesting is, I’ll put 6 percent into a column that says “will be done”, and 40 percent into a column that’s at risk, and I make this very visible to them. Often times, this causes them concern and gets them upset. Then I explain the key to them. The 40 percent that’s at risk doesn’t mean that it’s not important. All that means is that I’m trying to have an opportunity to protect your ability to change your mind. I want to give you, as an executive or a thought leader, or even a product owner, an opportunity that as we progress through the iteration cycles … as we progress through sprints … that if you see something, that you say, “I want to capitalize on that, or I want to add something there,” that you have an opportunity to do some course change or some direction, and you have a good opportunity to inspect and adapt.

This model, working with executives … if they do introduce something new, great. We’ll move that into the “will be done” pile. One of the items in the “will be done” stack will move to “at risk”, and something of equal size and value from “at risk” will move into the “not be done” category. This gives them a clear, visual representation of the cost of moving something into a project that’s new, or the cost of changing direction.

I know what you’re thinking already. Lots of times executives say, “Well yeah, I want this, and I want that, too.” That is a possibility, but once again, if that happens, that’s going to make the date slip. We have to make sure that we have a clear understanding of the three integers that are at play; that triangulation, and that we show, using a chart very similar to this – and I make it very big and very bold. I make it very presentable, and I make it always available to any manager, executive, or anyone who’d like to see this. This is a publicly available chart, and I use it either based on a project level or a release level, depending on what you’re trying to tackle, and how large or small the organization is that you’re working with.

Page 4: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 4 -

Once I make that available, then it makes this part easy. Instead of doing a traditional three to four months, if you look at those letters in the middle, it’s January, February, March, April, May, June … instead of doing a traditional three to four months’ requirements analysis gathering and planning, the small design, the heavy coding unit testing, anti-bugging with teams all over the world, and wind up presenting a product that undergoes much greater testing at the end, only to find that 20 percent of the features are going to be used … the Agile approach obviously teaches you to work iteratively through those features, so that you’re only focusing on the two to three things that you really, really want each sprint.

Then what happens is, as you’re delivering potentially shippable items over the course of these sprints, you’re going to deliver things that not only are higher value to the organization, but things that are going to make sense to the end consumer. I know that’s just a high level piece; that’s the overview. I just wanted to make sure we’re all on the same page.

When we go through and we start creating the user stories, this is the base of where we’re going to get our estimation from. We need to make sure that we’re very specific, and from the very early days of Agile, no matter which method you go with, they always start it out with something as simple as a story card. The card represents, of course, a 3 ½ x 5 index card. It represents the maximum amount of information that we want to take in with us, in order to feel like we have a good description of what we’re trying to do.

Second is the conversation. The conversation gives us an opportunity to talk about the details of what’s going to be … need to be done, in order to achieve what information is listed on the card. I love Jeff Patton … a dear friend of mine … put it this way. One of the quotes he said is, “The card is a placeholder for a future conversation.” You never want to make the card the end-all, be-all. You never want to make the card too large or too intensive. You want to make it a placeholder for an additional conversation to take place.

Finally, you have the confirmation. The confirmation includes all the acceptance criteria, all the test cases and packages. That way, we can go back and review and say, “Yes, we have met everything that we need to do, in order to deliver this.” This is the part that people have the most struggle with; taking this information and getting their head around time, or the time that it takes to do something.

What I’d like to ask for you to do, is at this point, forget about whatever estimation method you’re using currently. Just for a few moments, take the time to rewind the clock and say, “OK, if I were starting from scratch, and I had this to do all over again, what steps would I take in order to ensure that I had the best and most accurate way to estimate?”

What I’m about to show you is going to revolutionize or change the way that your thought process goes. This part’s not, because it’s the obvious card overview. What we do with the information in these three corners, is going to revolutionize the way that your thought process

Page 5: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 5 -

works. Let’s give you a quick overview of the card; just a quick introduction. We’re going to go into detail about each one of these corners in just a moment.

For beginners, the title. I always say 10 words or less; keep it quick, to the point, make sure it’s something that’s easy to understand. For the description, as a personal or role, I’d like to execute this action and perform this activity so that I can achieve this end result. Or, the way I like it better, as a who, I’d like to do what, so that why; the basic core of all of our stories.

In the top left corner, we have business priority. Business priority is going to be the strategic value of this particular item … this particular card … to the organization. Does it have a high ROI? A low ROI? Is it something that places us in a better strategic advantage against our competitors, so it’s a competitive marketplace? This is one that we’re going to dive into a little bit more in just a moment, but I wanted to give you a high level overview.

Top right, you have MoSCoW. MoSCoW is going to be from the consumer perspective, and that’s must have, should have, could have, or would like … we’ll talk more about that, but that’s going to gauge how your consumer feels. Finally, a T-shirt size. T-shirt size, conceptually, is something that many people are used to, but many people don’t use. I’m going to express why it’s important, at least initially, to start with a T-shirt size, and where that T-shirt size can take you.

Once again, basic description as a role or persona; I want to perform this action, execute an activity, so I can see or achieve an end value result, a benefit. One of the things that I really do drive home is, I like to use the roles and personas to frame up the who. That forces us to start thinking in terms of the person behind who’s going to be using our product or service; who’s going to be performing activities? What their expectations are, and how can I ensure that they’re getting value out of whatever I’m producing?

I we keep doing that, instead of only having 20 percent of what we build being used by our end consumer, that’s going to increase dramatically, because we’re always putting a consumer’s name right there in the story as Susie; I would like to log it to my account, so that I can check my balances and transfer money from savings to checking, if necessary … something very similar, very simple, easy example.

Once we have all this information, which we haven’t covered in great detail yet, then we’ll be able to go through and put our backlog in order, and do things in stack ranking, from highest to lowest; put everything in a true pecking order. Of course, the product owner’s going to come in and have opportunities to add new features, just as we described earlier. Features can be re-prioritized at any time. Features can be removed at any time, so you have an opportunity to move things around, remove things, change things, and do anything that you need to do in order to ensure that you are at a point to be working on the things that are most relevant for that particular sprint, or for that particular release.

Page 6: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 6 -

The question is, how do we establish this pecking order, and how do we get to the crux of the estimation piece so that we can tell our executives or leaders, with confidence, how long something’s going to take? That’s where we rewind, say, how far in advance are we preparing our product backlog? Are we doing a solid release planning session? From that release planning session, are we taking opportunities to meet with developers and the teams that are going to be working on this early, so that when it comes time to do our sprint breakdown, and comes time to break things down into tasks, that we can map that with assurance and feel confidence about what we’re doing.

I think that from these transitions, where you’re breaking things down from a solid product backlog into multiple releases, or maybe spanning multiple teams or organizations globally, and you’re spanning it down and breaking it down into the smaller bite-sized iteration level, that’s going to be where you see the greatest room for error. Each of these, interestingly enough, should have a small number of people increasing to a larger number of people who are participating. Let’s give you a quick example. For the product backlog planning and grooming, often times I say when a product owner is preparing their backlog, that it’s important for them to include themselves, one person from the business side to help them determine strategic readiness, return on investment and all that good stuff.

You should have somebody from the consumer side, or a representative from the consumer, who speaks on behalf of the consumer, about the consumer’s wants, needs, whims and desires; maybe things they’re struggling with, things they’re clamoring for. You should also always try to include someone technical in the discussions, so that they can tell you technological feasibility or what’s happening, while you’re creating the backlog.

For that product backlog initial design session, and for subsequent Q&A-type short sessions, I always recommend that you have at least four individuals participating in that meeting. I often call those, or refer to those four individuals, as a product ownership group, or product ownership team or cloud. This way, you have a group of individuals that are represented.

At the release level, the next level down, this is where it gets interesting. I think that you should involve all the teams who are going to be participating in a release, so if there’s multiple teams, let’s get them all together. Let’s sit them down in a room for a short time, and make sure that they have a core understanding. One of the faults or breakdowns, or one of the things that we do incorrectly when we’re doing this part of release planning, is that we do involve the teams, but we spend a lot of time talking about the things that we already know about.

One of the core tenants of Agile is to get to the point of talking about the things that are less comfortable to talk about; the things that we’re uncertain of, and spend less time talking about the things that we already know. This is uncomfortable for developers. It’s especially uncomfortable for testers, but it’s one of the core tenants that’s going to make the rest of this

Page 7: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 7 -

planning process work. When it comes time for release planning, we’re going to involve a larger number of people at the same time, so we can get similar sizing. We’re going to involve people who are in the know, so that they can give us feedback and ask the right questions, and we’re going to make sure that by the time we get to sprint planning … which is later you see there … the duration planning … that the teams have already had an opportunity to review the backlog … they’ve had an opportunity to see these items in release planning. By the time it gets to sprint planning, it’s old hat. They’ve seen these items, this will be the third time. They feel confident about the items that they’re estimating and breaking down.

Let’s make it real. Let’s go in, now that you understand fundamentally what we’re trying to do, and why we’re trying to do it … now let’s get in and do the nuts and bolts. The truth is, when I go to any business … and I’ve been to hundreds … and I ask them, “Tell me, from a return on investment or a strategy perspective, from the business side of the house, what value does this item have?” I always get the same answer. There’s high, really high, and really really high.

I think that part of that is instilled from fear; fear that if they say it’s anything other than high, that the item won’t be worked on, or won’t be addressed, or won’t be done. The truth is, we need to get product owners, executives, leaders and managers to understand that just because something isn’t labelled “high” doesn’t mean that it’s not going to get done. We need to reset our thought process and say, “OK. Everything that you’re asking us for is important. If it wasn’t important, you wouldn’t be asking us to do it.” There can only be a certain number of items that fall in the high priority category.

With that being said, a couple of tips or games you can play. One is dotmocracy .org here. It’s dot voting; basically, you assign a certain number of dots to a product owner. All the items are marked to low, and there’s a cost; three dots moves something to medium, seven dots moves something to high, and when a product owner’s out of dots, the remainder of the items for that cycle remain low. That’s a great way just to teach them that low doesn’t mean not valuable or unimportant; low just means that other things are more important.

You can do the same thing with innovation games. My good friend, Luke Hohmann … he has a game called “Buy a Feature” that you can use for this very thing. If any of you innovation games folks out there … this really does work well, and it’s another opportunity for us to drive home the understanding that everything doesn’t need to be a blazing high priority in order for it to get done. Once again, we need to realize that this is from the business perspective, and that they are going to be the ones filling in this information.

Hemant: Lee, let’s take one question.

Lee: Yeah, please.

Page 8: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 8 -

Hemant: When you showed the original particular index card of the story, on the left side … top left … you had this item, business priority; on the top right, you have the MoSCoW and user. Does it ever, or does it often, make sense to combine these two into one kind of unified list of priorities? Just to talk about what is the prioritization of a feature, rather than separate them into a business priority and end user priority?

Lee: Good question. I appreciate the question, it’s a great question, and it’s one that I get visited with often. There is only one time where it’s appropriate to look at the business priority and MoSCoW as one, and that is if you’re a services organization, and you’re building things for internal consumption within the organization. If I’m building something for internal consumption, sure, you could look at those two as the same value. Obviously, the things that are going to be the highest priority are the things that you must have.

However, without having covered MoSCoW first, I want to give you a quick example of where these two could play against each other. I was in an organization once where the business priority was, “We’re working on our Web strategy. We’re focused on the Web strategy. We need to make our entire catalog Safari-compliant.” This was what the business wanted, for whatever reason. They said, “We need to make everything we have Safari-compliant.”

The consumers were sitting here, pulling their hair out, saying “It’s absolutely ridiculous. We need a mobile solution. We need a mobile strategy.” The things that were of the highest priority to the business, were actually things that the consumer could care less about. The consumer’s screaming, “Hey, we want a mobile solution,” and the business was saying, “Well, that’s our lowest priority, because we’re focused on the Web solution first.”

I’ve seen opportunities where these two do play against each other, especially if you’re in a B to C, where you’re trying to appeal to consumers, whether it’s retail, entertainment, any of those type things. I’ve definitely seen where those two don’t jive, and actually do fight against each other.

One of the strategies that I’m going to show you is, once we cover all three … we’ve started with business priority. Once we cover MoSCoW and T-shirt sizing, I’m going to give you a hint or an idea of how you can use a formula to triangulate these three, to help determine a pecking order for the product owner and a backlog. That was a great question. Did you have another, or are we going to continue?

Hemant: No, I think let’s continue. That’s good. I think people … you may want to just again remind people of MoSCoW. People are asking again, “What is MoSCoW?” Just, if you can go over it.

Lee: We’re … that’s the very next place we’re going. We’re going to talk about priority. We’re going to talk about timing; time versus relative complexity, and then we’re going to talk

Page 9: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 9 -

about MoSCoW. To give you a short answer now, just to refresh everyone’s memory, MoSCoW is … it was originally created by Mike Cohn. It stands for must have, should have, could have, and would like. These are measured from a consumer’s perspective.

Just to give you a quick … I can skip over and do that one first, so there it is. Must have, should have, could have, would like. If I were building a banking Web site from scratch, for example … even though I, the consumer, might not know what this is, a data base schema is a must-have item. I’m not going to go and visit a banking Web site, if it’s just a static list of locations for me to go and check a balance on my account, or transfer money. I expect to be able to do on line banking. That’s a must have. That’s a deal-breaker for me, right?

A should have is something that, it’s not necessarily a deal breaker, but it’s something that logically really should be there. A good example of that would be access to all of my accounts with a single log in. I have seen some investment companies where you needed to have different log-ins, to see … to have access to different accounts, and you couldn’t ever see everything on one page, and it was quite frustrating. In this day and age, people would expect … for crying out loud, I want to see all my accounts in one place. That might not be a deal-breaker; if you have a secure industry, and it’s necessary for you to use different log-ins, so be it. In this case, it’s something that you really should have.

A could have, in the same example, might be display today’s 30-year fixed APR. I might not be looking for a home loan, but there may be someone else who is. It doesn’t offend me or bother me that that information’s there, but it’s not necessarily something that I would use. It’s not something that I need right away. It could be there; it could not be there. Once again, from my … the consumer perspective … I could care less. It’s the same as having a cassette player in a car. It doesn’t bother me that it’s there, I just don’t know that I’d ever use it.

Would like is the interesting one. That’s, “We need more cowbell.” If you want to go a little deeper, it’s the, “You know what would be really cool?” If you ever start the sentence with that, you know you’re going for a “would like”. A “would like” on a banking Web site once again might be, “I want to talk to a specific teller at my branch, somebody that I know, that I’ve worked with before, that I’m familiar with, to help me sort through a problem that I’m having with my account,” or whatever the case may be. It’s a really … I don’t want to call it whimsical, but it’s a feature that’s highly desirable; almost like a pleaser in a Kano model. It’s something that we should strive to do, but not something that’s going to take precedence over something that’s a must have item.

With that model in place, you can see here that we’re measuring consumer satisfaction. We’re measuring how the consumer is going to react to what we’ve built. We’re measuring whether this is a deal breaker for the consumer, or something that they could live with, whether we have it or not. This one … MoSCoW … is probably the glue that holds it all together. That’s why

Page 10: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 10 -

I like to do it last. Because we had so many questions, I went ahead and fast-forwarded a couple of slides to make sure that we could see that, so that everyone was on the same page.

In each one of your sprints, you should probably have some mix of these. Your initial sprints are going to have a lot of must haves. As you cycle through, you’re going to see that you’ll float in some should haves and could haves, but every sprint is going to have at least one would like, which is rather interesting. The last thing you want to do is get to your demo, and have everyone waiting there and say, “Ladies and gentlemen, boys and girls, I present to you the data base schema.” They’ll never come to another one of your demos again.

You want to make certain that you’re presenting something that has value to them each sprint; something that is tangible that they can hold on to … something that’s enjoyable. Something that they say, “Wow. They’re thinking of me. That’s pretty cool.” Doesn’t need to be something monumental, but it should be something.

I’m going to do something a little unorthodox. Since we’ve talked about MoSCoW now, I’m going to rewind and talk about the core reason you’re here today, and here it is. Ready? We’ll rewind, and we’ve covered business priority. We’ve talked about using innovation games and Dotmocracy to make sure that we had that covered. We’ve talked about MoSCoW. Let’s talk about the big one. Here it is; the big hitter … time versus relative complexity.

I don’t know how many sports fans I have on the phone right now, but I’m going to use a quick sports analogy or example. I am a big fan of football, especially “Monday Night Football”. If my wife or significant other or your spouse calls down, and there’s 30 seconds left in the game, and they ask you, “Hey, how much time’s left? How much time do you need? How much longer is the game going to be?” Your answer is going to have two things in common. Your answer is going to be time-related, and it’s going to be consistently wrong.

I’m not saying that to be ugly or mean, but the reason is, any time you have those type of opportunities, where there could be time outs, or stoppage in action, or stoppage in play … we just do terrible at gauging how much time something takes.

The similar example … the one on my screen … I don’t know if you’ve ever had an opportunity to paint a wall, or to paint a room before. My goodness, it is the perfect example. Each one of us probably has had some experience doing some minimal painting job. If you have, and I asked you, “How long would it take you to paint a wall?”, you could answer and give me an idea. You may be a little bit close. The fact is, trying to pin it down to be incredibly estimation accurate, is just faulty. It’s false witness. I don’t care how many times you paint the wall, you’re not going to be able to tell me exactly how long it’s going to take.

The truth is, that different people who are hired as painters, have different skill sets. They have different tools. I, myself, would be an amateur painter. I’ve painted walls in my home before,

Page 11: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 11 -

but I certainly wouldn’t consider myself professional. I do have a sprayer, and I look the part, but it doesn’t mean that I’m going to do it any faster or slower than the next person who might also be an amateur painter.

Where am I going with this? Mike Cohn taught us something incredibly valuable. Instead of trying to always focus on how long something is going to take, if we can determine how difficult something is to do, we can translate how difficult something is to do, into an average amount of time to do similar things that are equally as difficult, and that will allow us a better opportunity to get a solid forecast. Let me give you an example.

In the example of painting the walls, the wall size never changes. What do I mean by that? If I say that a wall is small, and we all agree that a wall is small, tomorrow we’re not going to come in and say, “You know what? That wall’s medium.” If we went and looked at multiple other walls, the greater number of walls we look at, the more confident we would be in that estimate in saying, “Hey, compared to all the other walls, that’s a large wall. This is a small wall. This is a medium wall.”

Truth be told, professional painters use this model all the time when they go into paint large buildings or apartment complexes. If you’ve ever gone to get your auto repaired before, they use the same model. They can flip to a book and tell you … once they know what’s wrong with your car, they can flip to a book and they can tell you exactly how much the labor’s going to cost, because they have an estimate over time that says, based on this type of repair taking place, this is how much it’s going to cost, this is about how long it’s going to take.

In actuality, sometimes they don’t even tell you exactly how long it’s going to take. They’ll focus on, “How much is it going to cost?” or “How difficult of a job is it?” They’ve been trained to do this, because the truth is, when it comes down to who’s doing the work, you’re going to see varying skill sets, varying levels, and it could make the time vary.

I know that doesn’t instill a whole lot of confidence in people who are here to walk away with a perfect estimation. I think that what I’m about to show you is going to help tremendously. Mike Cohn started solving the problem. He said, “Instead of doing time, let’s do relative complexity.” In fact, he introduced planning poker.

I’m certain many of you have played this game before, but just in case anyone hasn’t, I just want to give you a quick one-round summary. We go into a room; usually we wait until the last responsible moment, which in this case we’ll pretend is a sprint planning meeting. We go into our sprint planning meeting; our product owner welcomes us to our sprint planning meeting, describes our goals for the session. Our goals are going to be to increase customer satisfaction over the next couple of weeks. We’ve had some issues we want to make sure we solve.

Page 12: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 12 -

The first backlog item is backlog item number 972314, adjust the parameters. As an end user, I’d like to adjust the parameters so that I can have a more enjoyable user experience. Any questions? Of course, the hands all fly. Many of the developers have detailed questions, they want a deep dive. Some want to be spoon fed information. Others just want to get on with the estimation process. Finally, it comes time for us to vote. We all … one, two, three … hold up our cards. I put mine on my forehead, and you put yours on yours. I have a three, and you have a five. “Tell me, why do you think it’s five?” You have five minutes or so to say why you think it’s a five. I have five minutes or so to say why I think it’s a three. Other people on the team may chime in with a couple of small questions. The product owner may have something small to say, and what do we do? We vote again, because the cards say that we have to have consensus.

We vote once more … one, two, three. This time, I have a five, you have a three. “You were convincing.” “No, you were convincing.” Haha, somebody else voted one; we tell them to get with the program. One, two, three, we vote finally and we all come up with three. Just from a time perspective … just to make sure we’re all on the same page … the estimate for that one card took us roughly … they don’t all take this long, but roughly 20 minutes. Let’s just say we’re doing an average two-week sprint, with a team of seven. You have about 10 backlog items in, so we’ll just say nine to go. Nine times 20 … you’re three hours in. Three hours in to this estimation game, what do you have? You have story points. That’s great, but now comes the golden question.

The senior executive, vice-president of most important things leans over to you and says, “Three what?” I know that for many of us agilists, that question is easy to answer. It’s a unit that’s not time-compliant, that’s non-comparable from team to team, that is a relative measurement of complexity. We have this answer, but the truth is … and I’m going to flip the tables for a second … one of the roles that I have played, I’ve played as a “C”-level executive … CTO or CEO in four different organizations, so here we go.

When you tell me a number, as an executive, and you say, “It’s a three,” the first thing that crosses my mind is time. Is it three hours, three weeks, three days, three minutes, three months? Give me something. Your answer is, “No, it has nothing to do with time.”

My second guess is going to be, “It must have something to do with money. Is it $3, $300, $3,000, $300,000?” The answer is, “No, it doesn’t have anything to do with money.” Now I’m getting a little frustrated, but I’m going to give you the benefit of the doubt with this Agile thing. I’m going to say, “OK, it has to be some other known unit of measure. Is it three people? Three stones? Three inches? Three miles? Three pounds? Three … it’s got to be something I know.”

When you come back with the answer as “no”, my confidence in that estimate has significantly dropped. With experienced teams, who’ve shown a record of consistency, not the case. For

Page 13: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 13 -

beginners, and for people who are struggling with estimation … which many of you may be, if you’re on this call … I found a solution that makes it a little bit easier. Call it a bridge, if you will; I’ve had some people even try to call it a crutch. Here’s what I’ve come up with, and I’ve proposed this to Mike. Mike and I have had this conversation.

I said, “You know?” I said, “Why don’t we start with a T-shirt size? Everybody knows what a T-shirt size is.” There’s extra small, small, medium, large and extra large. Notice I’ve married them back to one, two, three, five and eight. I’ve married them back to the modified Fibonacci scale.

What’s great about this is, in that same exact scenario, if we all looked and agreed that that item was medium … when the senior vice president of most important things leans over and says, “Medium what?”, our answer is simple. “This item is medium in complexity compared to all the other work that we have to do for this release.”

Now comes the big question; “How long does that mean it’s going to take?” To which our answer is, once again, quite simple. “At this point in the process, I can’t tell you the exact number of hours or minutes, because I don’t know who’s signing up to do the work at this point. What I can tell you is it should be completed around this time frame, or around this sprint.”

Now, the executive has confidence, because they realize that different people have different skill sets. They realize that you’ve given them the best estimation you could, and they realize that with that information, going forward, they can forecast. There’s another very famous quote that I want to drop here, and it’s a really good one. It says … it was Jeff Patton. He says that, “Our estimates should always be accurate, with varying degrees of precision, or varying levels of precision.”

There’s a huge difference between accuracy and precision. Accuracy means we can hit the side of the barn. We’re accurate, we know what direction we’re going in, we can hit the side of the barn. We’re not going to deviate from our path. Precision … if you’ve ever done any kind of skeet shooting or target shooting … precision is how tight you can get your grouping, or how many you can get in a small, small confined area. With that being said, the closer we get to actually executing the work, the more precise we’re going to become.

The trick is not to try to nail precision while we’re at the release planning level, but try to nail accuracy, and make sure that we’re accurate. With that comes one additional caveat. In order for all of this to work, there’s one key message that needs to happen. There’s one key thing that needs to take place. Your team needs to understand commitment implicitly. I’ll say it one more time. The team needs to understand commitment implicitly.

Page 14: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 14 -

Where am I going with this? Your team members need to be able to go in and say, “This is the amount of work that we can consume in a sprint.” If they’ve traditionally done 14, 17, 20 points … whatever the case may be … and then all of a sudden this sprint … somebody goes on vacation, and they only feel like they can do 12. We need to fine-tune to make those adjustments, and we need to … we need to get the team convinced.

This is something that, as an Agile coach, I position very well with my teams. If you haven’t heard anything else in this entire Webinar that you want to take away, please take this last piece of information I’m about to share with you. This is probably one of the big things. Ready? When I meet with my teams, one of the things I drive home with them is, as your Agile coach, as your mentor, as your leader … what my intent is, is to defend you and protect you from every outside obstacle, from everything that’s happening, to ensure that you have every opportunity to be successful … to make sure you never miss the baseball game, football game, dance recital, piano recital … whatever is going on in your life, you need to take care of those things. The truth is, you only live this life once.

If someone comes to your funeral and says that you were the best project manager ever, I have issue with that. You need to … or you were the best product owner ever. You have other things that you should have been doing in your life. Where am I going with this? There’s only one thing I expect in return; that when you commit as a team, and you say you can do these five items, or seven items, or ten items … I don’t care if you’re out rock climbing in Utah and a boulder falls on your arm and crushes it and you need to cut off your arm and mail it back to the office to get the work done. You committed to those items, and you’re going to do them.

People often disagree and say, “Wow, that’s pretty harsh.” If you put it all together, it actually isn’t harsh. What I’m asking the team to do, is to work within their means; to not always try to hyperextend themselves. Even if it means taking on one less story per sprint, I would rather have a team who consistently gets everything done, every single sprint, so that I could use that as an ability to forecast accurately, than I would have a team who consistently misses every single sprint.

The key here to drive home, is to make sure teams understand accountability matters. They need to be accountable for their actions, and that’s one of the key things that they need to take away, and if they do that, that that’s going to help ensure that this is going to lead us to success.

Once the team matures, if they want to do away with the T-shirt sizes and go back to numbers, I’m great with that. I use one, two, three, five and eight; if it’s larger than eight, it probably needs to be broken down. If it’s smaller than one, it’s probably a task. Of course, I reserve the higher numbers … 13, 20, 40 and 100 … for the product owner use; to say, “This is small epic, medium epic, large epic, et cetera.” The infinity card … you’re asking me to do the impossible.

Page 15: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 15 -

Zero is the free card; I know something you don’t know, this is already done. I usually discard the half. The question mark means we need more information.

This deck of planning poker cards doesn’t go away. It’s the same as what you have traditionally, and it’s used to estimate. Once you have that number, and you understand MoSCoW, and you’ve captured MoSCoW, then you can go back to that card, and you can say, “OK, what things should I be working on first? What are the items that should be worked on first?” It becomes quite obvious when you think of this.

Mike Cohn had a very famous quote that he said in the conference, and it made everyone laugh. He said, “The customer’s always right, unless they’re wrong.” I really loved that quote. It was quite humorous when he said it. What he meant by it is if there’s ever an opportunity for us to gauge the consumers’ wants, needs and desires against a business wants, needs and desires, the consumer should win every single time.

Where am I going with this? The items that we should address first, are the ones that are must-have on the MoSCoW scale, and high priority; simply because they are must have items or deal breakers, and they’re high priority. If you have a whole bunch of those, you should try to work on the larger ones first. Jeff Sutherland said we should work on our rocks before our sand. Work on the more complex architectural issues and get those nailed, before we work on the finite, granular things that we end up having to rebuild a lot of stuff.

After we do our must have highs, we should try to get in at least one would like; something small, something non-monumental, something that just shows them that we’re paying attention. Then you’re going to do all of your must have mediums, must have lows, then your should haves … high priority, medium priority, low priority … could haves, high, medium, low.

If you kind of use that as a gauge to triangulate your cards, what you’re going to find is that they fall in a different pecking order than what you’re used to. They call completely different than what a product owner traditionally plans, because your focus is now more geared towards what the consumer’s wants and needs are, as opposed to what the business strategy is.

I’m not saying that that’s a permanent relationship. You can take that, once you’re finished, and modify it as much as you need to, and massage it as a product owner. If you have hundreds of items to go through, that’s a great scale and a great way for you to map things together and match things up, so that you can see things in the pecking order.

The truth is, once you have the team committed, they can establish a velocity.

Hemant: Let’s take a …

Lee: Yes, a question?

Page 16: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 16 -

Hemant: Yes, sorry, Lee. Let’s take a question before we get moved off that topic.

Lee: Sure, absolutely.

Hemant: You went through the prioritization, which is very thoughtful. In the early part of the Webinar, you had shown that one page for executive communication where you had three columns of over 60 percent would be done, and 40 percent would be done. That listing of what will be done, and what is at risk and what is not getting done … how does that map to this prioritization that you just talked about, everything in that list?

Lee: Beautiful; that’s great. Good question, again. I appreciate these wonderful questions, and I encourage you, please keep them coming. This question; it does have a mapping. It’s just, they’re two different conversations, so I want to make sure I focus on that. The initial conversation early on was with executive leadership teams, conversations across product owners, conversations across portfolios. I want people to really see across a whole breadth of an organization. Which things are we going to focus on? Which initiatives are we going to take focus on? How many people do we have that are available to do the work, and how many of these high-level initiatives, road map items, or even high level epics … some organizations that are small get it broken all the way down to the backlog item level, and that was the slide that I chose to pull to show to you today. Most organizations do this at a higher level, and they do it with a higher level group of people, so that they can determine which things are going to be broken down.

The secondary conversation that we just now had about the must have highs, must have mediums, must have lows, et cetera … that is at the backlog item or story level. That’s once we’ve already done our release planning session, and we feel confident about our estimates, and prior to sprint planning. Somewhere in that range, where we’ve done our release planning, we feel good about it, we have good acceptance criteria that’s starting to become even better solidified, and we’re feeling good about where we’re going with these estimates.

This is done at the story level, so it’s prior to being introduced in the sprint, but certainly at a much more granular level than the other conversation that took place earlier with the 60/40. I really do appreciate that, because that is probably one of the most important questions that I may have glazed over, so I apologize.

Hemant: Thank you.

Lee: When it comes to understanding velocity, the velocity is simply how much work the team can do per sprint. Given over a period of time, taking their average, we can figure out once they’ve stabilized, without cutting corners on quality, without padding your estimates, without linking this directly to capacity planning by hours; how much work can a team get done?

Page 17: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 17 -

If we have the team’s confidence, even if it’s a little lower initially than we want it to be for the first two or three sprints … even if they’re not reaching for the stars, and just really doing what they can do … once again, I want to reinforce, I’d rather have a team with a consistent win velocity, that shows consistently what they can achieve, so that I can use that to forecast over time with better accuracy, than a team who sometimes wins and sometimes loses, or sometimes doesn’t finish, et cetera.

Each time that they do not successfully complete the items in their sprint, that’s an indicator that … it’s a red flag for executives or leadership like myself to say, “Is this Agile thing working? What do I have to do to ensure where am I?”

A quick example on velocity, because I often get questions on this. If team A is working in two-week sprints, and they were estimating all the work together like I described, and they consistently deliver between 18 and 23 points, you can reasonably expect team A to deliver roughly 20 points for a two-week sprint, and use that for forecasting purposes. If there are eight two-week sprints in a release, I can extrapolate team A is going to do about 160 points.

This is the model that executives need to gain confidence in. This is the piece where the leadership managers … they don’t have confidence at this level. Part of it is because, well, developers do pad their estimates. QA doesn’t have enough time to do testing. We haven’t done minimal marketable features, or imposed work in progress limits. There’s so many pieces that you can do to make this really gel and work well together. I think the core pieces are one, make sure the team knows that they need to focus on what they really can do, and really drive that home.

Two, we need to make sure once we have an understanding of what the team does, that we’re not trying to constantly stretch the team, that we’re going to use that as a consistent measure going forward. But three, that once the team commits to this, that they actually have to do it. On the backside, the product owners now have a formula they can use to better situate their backlog, to help reinforce this; to help reinforce that the teams have what they need, and that velocity is being followed.

A quick summary; size or complexity … question?

Hemant: Lee, let’s take one question on velocity before you move off of velocity. The question is, the consistency of team composition is, I guess, a key assumption when you are able to predict the velocity. What if the team makeup is just not consistent? Is there any advice on using velocity?

Lee: This is one of the biggest challenges that I face when I go into organizations. I’ve been to 41 of the Fortune 100 companies, and this is probably the most difficult message for me to send them. Please, if you’re a leader or an executive listening on this call, the number one

Page 18: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 18 -

most important thing that you can do for your teams, if you want to give them the best holiday gift ever; keep their teams consistent.

If you can keep teams consistent, you’re going to gain huge benefits including the benefits described here, where you can do the forecasting based on a team’s velocity. If you constantly have inflow and outflow of individuals … if you’re constantly re-arranging people … that’s usually what I call an Agile smell, or a symptom that something else is wrong. Without being a coach specifically on the ground there, I’m going to give you a guess, and I’m probably right, but I’ll throw it out there. The guess usually is that, instead of focusing on organizing the work better, and keeping the teams well organized and letting the teams swarm to do the work, that this is usually an indicator that the company has too many plates spinning.

In other words, they have … instead of having five projects going on at one time, and trying to get those five projects to completion, and then kicking off the next five, they typically like to have 10 or 15 or 20 going on at the same time. In order to do that, you have to borrow people from each team; go swarm over here and keep this plate spinning, then go over here. What that does is, it devalues both team composition and that accountability model. You need to be careful.

My recommendation, obviously, is to keep teams as consistent as possible. If you don’t have consistent teams, this is going to be really hard to do. My advice would be just to use a mathematical formula, and try to divide over the last several sprints, even with fluctuation, and see if you can come up with something that’s reasonably consistent. If I know my teams have constant inflow and outflow, I try to keep that on the low end of the estimation side; the low end of the average.

Hemant: Thank you.

Lee: Size or complexity is estimated, velocity is measured over the course, just like we just now described, and duration is derived. If you can remember these three key things; that a story is estimated in story points based on relative complexity, the team’s velocity is measured on what they can deliver in a two-week or three-week sprint, and then based on their measure of velocity, we can figure out what the duration is over time, as long as we have the teams consistently delivering; that’s the key. We need to make sure that we instill that confidence model in them.

Instead of having the question about how long we should be focusing on, how big? How difficult? Once we get that together, then we can use that to replace that, and executives become happier with their estimates, because we’re getting to the core.

Just one last thing here, just to make sure we’re all closing on the same page. We should be focusing on a vision for our product, up to a year out. You see, I have T minus 365 there? Up to

Page 19: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 19 -

a year before we’re planning on doing something, we should be focusing on what our vision is, and our strategy; how we’re going to achieve it.

Once we understand our vision and our strategy, then we can focus on road mapping. Road mapping’s going to cover everything from a year out, all the way to 90 days out. Once we know what we’re doing 90 days out, that’s when we can start having those conversations internally, and brainstorming what our backlog’s going to look like. We have out backlog prepared, and sometime in the next 45 days, to sometime between T minus 90 and T minus 45, is when you’re going to have the backlog readiness. Then you’re going to take your ready backlog into release planning with you with multiple teams.

Once the teams have a chance to review the release plan, at T minus zero is their sprint planning meeting, which will be the third time that they’ve seen this work, so they’ll have no problem storming through sprint planning. Of course, the last level is their daily planning, where they have the two week sprint here as my example, T 1 and T 14 to actually complete the work.

If you are backing things out a little bit, and starting to focus a little bit more on the backlog item creation, and getting your backlog items prepped, so that by the time you get to release planning, you understand what the MoSCoW rating is, and what the business priority is … that’s going to really help your teams and organizations move forward.

Once again, I wanted to make sure I left enough time for questions. We’ve got about 10 minutes. I want to say thank you to all of you. I realize how valuable your time is, so on behalf of my family, in front of [inaudible 00:52:16], I want to say thank you. I want to allow for this … for a few moments for questions. Go ahead and take over.

Hemant: Thank you, Lee. In fact, you can keep the presentation control, so audience … people who are in this Webinar, I have a bunch of questions from you guys. Take a few more … a couple more minutes or so to jot down any more questions, and I’ll keep track of them in the Q&A panel.

While you’re doing that, I’ll quickly go over an overview. If you can advance to the next page, Lee, the one after this one. Synerzip, in a nutshell … you can build this out, so we can do it quickly. We are a software product development partner. Particularly, our clients tend to be small to mid-sized software companies, often venture-backed software companies.

What we do for them is put together a dedicated team of high-caliber software professionals. Echoing what Lee just amplified; very important in software development to have constant, consistent teams. That’s one of the key strengths of our work with our clients, is to keep constant, stable teams, who are consistently delivering Agile techniques for them.

Page 20: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 20 -

We have an off-shore development center, so we are able to provide significant cost advantage, and then also provide ultimate flexibility to our clients. Whenever they’re going … doing an IPO or getting acquired, or doing anything significant, and they want to take the team in their control, we can hand over the team to them. Constancy and caliber of team is very important in our work.

The next page shows a glimpse of some of our clients. You’ll see a mix of a few large companies, but mostly small to mid-sized software companies, typically venture-backed, doing cutting edge, leading edge work.

With that, let’s kind of turn our attention to taking some questions. Let’s take the first question here. The question here is, in the estimation part, Lee, the question is, if some team members are better at estimating than others, is it necessary to involve the whole team for a story point estimation exercise, or do you only involve people who are, from your experience as a Scrum Master, are good at estimation?

Lee: Great question. Typically what I like to do … and this alarms people … is I’m a big advocate of rapid release planning. What that means is, I actually ask for an initial estimate on complexity at the release planning level, before it ever reaches sprint planning. That does two things. One, it helps ensure that as we better flesh out acceptance criteria, that we’re on the same page as the product owner, so that we have a good understanding. Two, it allows for the team to feel more comfortable committing, because they know more about the item.

When it comes time for release planning, I want the whole team to be involved, but this is how it pans out. It’s quite interesting. To give you an example, there’s a large software company in Redmond, Washington, that manufactures operating systems for PCs. I had an opportunity to work with one of their teams there, who was working on a studio that was very visual. While we were doing their planning, one of the things we did was we invited all 42 team members to come in a room. We had 426 stories. We had 42 people in the room.

We literally … we checked each one … we reviewed the ones we weren’t certain about. We had six points of validation on the story size. We gave everyone a chance to move items onto the wall, into T-shirt sized categories. We identified dependencies, and we finished this entire process in just under an hour.

Where am I going with this? If you pick up an item that you’re not familiar with, obviously you’re just going to pass it on to someone who is more familiar with it. You’re just going to set it back down and let someone else pick it up. I only want you to focus on the ones that you’re most familiar with. By doing so, you end up with a solid estimate, because the people who are familiar with that type of item, do the estimate on those items, but you end up having a broader breadth. People who may have some familiarity may give a view on one item, and you still have the opportunity to change them on the wall. There’s lots of inter-activity there, but

Page 21: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 21 -

it’s a great opportunity and a great cycle for people to walk through. Maybe, perhaps in the future, that might be a good second session that we could do together; teaching about rapid release planning.

To answer your question, yes, I think it’s important to have everyone there during the initial estimation. Once we have the initial estimation in place, I think the final estimate, obviously, should go to the team and the individuals doing the work.

Hemant: Excellent. Let’s take another question, which I’m going to combine two separate questions in this one. The planning exercise … estimation planning exercise example that you went to, sort of assumed the up-front backlog defined at least at the epic level, so you may have something to the story level, and something at epic level, so you have those one through 30, or some such number, defined up front.

One question is, often that’s not the case; that assumption’s not true. Some complexity comes about along the way, some new features come in along the way, or significant new features come in along the way. The related part that makes this process complex for your practitioners, is that business executives still want a reasonably precise or firm dollar estimate to make a go/no-go decision whether this project or software development will be funded or not funded.

Lee: Right, OK, so I like that you combined those two. They’re two big topics, but we’ll hit it as fast as we can, so here we go. First, when it comes to funding a project, one of the big exercises that I do with senior level executives … and I’ve had an opportunity to do these with Meg Whitman and Richard Branson, Welch, others … is we really need to teach them to focus on more of a customer-driven value design.

Where am I going with this? At the very top, I have them focus on value stream road mapping; putting together press releases that define a vision and strategy of where you’re trying to go. Only funding projects that I feel like have a solid vision and strategy, as well as a good return on investment. I make those funding decisions, clear back at road mapping.

How do I present that to allow someone to make those decisions? I rely heavily on a product owner becoming familiar with exactly what they’re trying to build. Instead of spinning five plates, once again, I want them to focus on the one or two things that they want to focus on.

With that being said, the core understanding is exactly as described. New things are going to come up. People may want to change direction. Some of these big changes may be huge. The benefit of displaying that 60/40 model is that if something does come up and you want to change direction, you can.

Page 22: AGILE ESTIMATION WEBINAR DECEMBER 2013€¦ · AGILE ESTIMATION WEBINAR DECEMBER 2013 - 1 - Hemant Elhence: Welcome to today’s Webinar on the topic of Agile estimation. As you are

AGILE ESTIMATION WEBINAR DECEMBER 2013

- 22 -

The last thing you want to do is be behind the eight ball. I realize that with that change of direction, the person who is funding the project … your sponsor … may have said initially, “That might not have been the initial piece that I wanted to fund,” or that may not be … “I may have funded something differently, had I known I was going to come along this obstacle.”

I think that’s why it’s important to open up lines of communication that are clear and consistent along the way, starting with the vision and strategy, opening up a value stream road map that’s updated every 90 days … a rolling wave roadmap, that’s updated every 90 days with cutting edge, what is the top business priority? Involving executive and leadership in that vision piece, so that they can see it and say, “Yes, this is where we need to go, and we’re going in the right direction.”

If the changes do come up, it’s inherent. I’m going to use a quote from Meg Whitman at HP. She says, “Innovation is born of those changes.” You’re not going to get a cutting edge, corner-of-the-market type item, unless you focus in on … and be innovative, and allowing some of those changes to happen.

The good news is, you can still stay within your budget if you stay within the time frame. Once again, these are decisions that have to be escalated at some point, and it’s not necessarily a team level or product owner decision every single time. If it’s something that’s going to be critical affecting the budget, you need to escalate that.

Hemant: We have a few more questions, but we have run out of time, unfortunately, Lee. Let me promise this to the audience. You suggested another related topic, deep diving into rapid release planning, maybe we take up … sounds like there’s enough appetite to deep dive into that topic, that we take that as one of the 2014 Webinar topics.

Lee: Absolutely.

Hemant: We’ll also take questions along with that.

Lee: Also, I’ll entertain, if it’s of any benefit, to pass along some of those off line and we can include them as an addendum … a document, a .PDF addendum … to make sure everyone has an opportunity to have their questions …