Exceeding Customer Expectations with SCRUM
Danny Ryan: Hi. This is Danny Ryan and welcome to the ThreeWill Podcast. I’ve got Bruce Harple with me today. Thank you again, Bruce, for joining me for the podcast.
Bruce Harple: Absolutely. Glad to be here, Danny.
Danny Ryan: Great. We wanted to take some time in here. I was joking as we were prepping for this that we could probably talk on this subject for much longer than twenty minutes. I am going to try to hold us to twenty minutes, but probably a subject that’s near and dear to a lot of folks hearts at ThreeWill, which is talking about managing customer expectation and talking in particular about Scrum. Tell me a little bit about what you want to talk about today.
Bruce Harple: Yes. What I want to talk about Danny is when we think about managing customer expectations, we kind of talk about the Iron Triangle and three things that we want to really set expectations around and then manage throughout the life of a project is scope, schedule and budget. Of course those things all impact one another. So if one either increases or decreases, it actually does affect the other parts of that triangle. I talk about how our Agile Scrum process really helps us manage those three parts of the Iron Triangle, and how we kind of manage that on a regular basis with our customers.
Danny Ryan: Awesome. With this, it’s describing … you probably have to get started off with a couple of definitions of some important terms. In particular, for folks who are listening in, we use an Agile process called Scrum. What’s interesting about this conversation is, Scrum is typically used in large development shops. We are using it in the situation where we’re trying to develop products and applications for customers. Because we’re using it, yet there’s some modifications that we need to do to set those expectations up properly. So if you could, sort of at a high level, talk me through User Stories, Story Points, all that good stuff.
Bruce Harple: Yes. One of the key artifacts in Agile Scrum that kind of drives and really defines the scope of a project, is something that is collectively called the Product Backlog. It’s kind of an Agile Scrum term. Within a Product Backlog, there are a set of what we call User Stories. User Story really in one sentence describes a User’s interaction with that application and the benefit that might result as a result of that customer’s interaction or that User’s interaction with the system. A User Story is just a way for us to redefine a requirement into those three parts. There’s a User, there’s an Action, and there’s a Benefit. That kind of forms that baseline of the scope for a project.
Then one of the things that we do, another term that I’ll use is called Story Points. Story Points are the way that we actually size the effort to implement a specific User Story. A Story Point is just a number. We follow the fibinocci system, that could be anywhere from a point five up to a twenty or higher. The higher the number, the more difficult it is to implement that specific User Story. We assign a Story Point or a size effort to implement every single User Story. That really becomes the foundation for the scope. The scope is the User Stories. We actually take those Story Points and we actually convert those into hours. Once we have hours, we can convert those into dollars, which is your budget. That’s your Scope.
User Stories make up the Scope and then the Story Points converted into hours and dollars, that makes up your Budget. Then, we take those User Stories and group them logically into a sequence that makes sense to implement them, and also kind of grouping them by size. We group all those into Sprints. A Sprint is, typically we work in two week Sprints. A Sprint is just a duration in which you are going to deliver a certain number of User Stories to the customer. Once we take all those User Stories and size them with Story Points, we then group those into Sprints and those Sprints define the schedule. That’s kind of a baseline, kind of the Scope, the User Stories, the Budget is converted from the Story Points, and then a Schedule is the number of Sprints and the Spring Duration that we plan at the start of a project.
Danny Ryan: So these User Stories and the Story Points and this calculation of time and money, that all goes into the statement of work for the customer or how does that work?
Bruce Harple: Yes, that’s right, Danny. We actually go through this process during the sale cycle. As we talk to a prospective customer and try to understand their business problem, we really drill down into some lower level requirements, and actually build out the product backlog and all the User Stories. That’s been very successful for us from the perspective of … you know, customers love it when we kind of play back these User Stories. Because their reaction typically is these guys really get my business problem, they get what I’m trying to accomplish. We review that backlog with them in the sales cycle to make sure that we have correctly restated their requirements in these User Stories. We also go through them in the sales cycle, and for our ties, all those User Stories.
They tell us what items are must have items versus should have, could have, or if it’s a willing to have, it’s something that could wait until a later phase. We obviously size everything. Then those User Stories are actually grouped into something we call Feature Groups, which is just a logical grouping of Stories. Then, with that, and we size everything, convert it to hours and dollars. Customers can actually go through that and actually exclude Stories, exclude features. They can really take that whole product backlog and kind of get it sized to their budget. We end up working with them to help them determine what’s most important, where are they going to get the most value for their investment, and that’s where we establish that baseline. What is the baseline of User Stories that are must have, we have to have it in this release of the solution. Then what’s the side of that Story Points, that obviously gets converted to, as I said, hours, dollars, and a schedule.
Danny Ryan: Does the customer pay for this estimate?
Bruce Harple: No. That’s something that we do during the sales cycle. Now I will say when we start a project, in some cases there may be some requirements that we haven’t had the time to really vet out in detail. In many cases what we’ll do in the sales cycle, if there’s any kind of technical risk or uncertainty or any kind of requirement risk or uncertainty, we’ll tend to put User Stories in our backlog called Spikes. A Spike is just a story that says we didn’t have time to flesh out this technical concept or we don’t have time to flesh out this set of business requirements, so we’re going to allocate a little bit of time in the first Sprint of the project, that we call Sprint Zero, and further vet those things out.
At then we can at that point determine, once we’ve got more detailed requirements, or maybe we do a proof of concept to show if there’s a technical risk or to present a concept to a customer. We can say after that review and after those Spikes are completed, we can then sit back down with a customer and say this particular Spike is resulting in these results, which impact the product backlog in this way. It might not have any impact on the backlog, in the way of additional User Stories or anything like that, but it gives us another checkpoint after that Sprint Zero, which is the first Sprint, to re-calibrate, budget, Schedule and Scope if we need to.
Danny Ryan: Just to point out a couple of things that I think are really valuable. Mentioning that this is something we do as part of the sales process. For folks who haven’t gone through the sales process with us, Bruce puts together a very detailed spreadsheet. One of the benefits of having that is you can see where they basically get a breakdown on where the work effort and what’s involved. The other thing I like about that for customers is, not only can they prioritize things, but it’s almost like a shopping basket type of approach, where you can say maybe I don’t have the budget to go after this, but you can play through some scenarios. I know customers just love having that control over what are we going after, and help the customer basically size out the project appropriately. I think it’s just a great thing to give or to hand over to people. It’s fun going through the estimates that you guys come up with, and walking that through and then the customer seeing it and getting feedback from them is really awesome.
Bruce Harple: Yes, Danny. I think just to add to that. I think what customers really appreciate is that it lets them see and for them to implement a certain feature group or set of User Stories. Once they see a price attached to that, it really resonates with them. At that point, they’re making an investment decision. They can decide is my business going to get enough benefit from this Feature Group or set of Stories, and it’s worth making this investment. We’re just really trying to give them the data points that will help them make what we hope are the right decisions for their business.
Danny Ryan: So we start off with this statement of work that has a certain number of Story Points against it. Of course, the project starts, week number two something comes up. The business climate changes, something happens. How do we adapt to these changes that come up that we know will come up during projects?
Bruce Harple: Yes. Exactly. I mean anybody that’s been involved in custom software development knows that you need to identify new requirements as you go. Also identify areas that are more complex than you thought, to maybe implement a specific requirement or User Story. One of the things we really try to do is at the front of a project, go through that product backlog with our customers, explain how we phrase it. We explain how we size everything using these Story Points. We really try to educate our customers into thinking of the Scope of the Project being the number of Story Points that they’re going to get that are associated with this project backlog of User Stories.
That’s kind of the baseline that we kind of always go back to, to say we committed at the start of this that we would develop one hundred Story Points worth of features, for these hours and for this budget. We kind of try to use that as the baseline. In Agile, we talked about every two weeks we develop a set of features that we deliver to the customer. We go through a process called a Sprint Review, which is where you kind of review what you’ve accomplished with a customer. You cerebrate that. You take their feedback. Right. So if any adjustments need to be made you’re getting that feedback every two weeks.
And then, as a part of the Sprint Review, we also go into what we call Spring Planning. I talked about at the beginning of a project, we set a Sprint Schedule for all the Sprints and we take the backlog that we started with. We break it up into these Sprints. When I get done with Sprint One, for example, I’m going to go ahead and look at my Sprint Two plans, what I originally started. And when I do that, I’m also going to bring up, okay, so during Sprint One, we uncovered these five new User Stories.
We estimate that these five new User Stories are … lets say it’s ten Story Points to implement these five Stories. So one of the things that we do as part of Sprint Planning when we’re looking at that next Sprint, we sit down with the customer and we say we’ve got five new User Stories, five new sets of requirements. Are these User Stories or these requirements more important than what we already had planned for this next Sprint? If the answer is yes, some of these are more important and we need to have these included in the next Sprint, then we work with them.
If we’re going to take these new User Stories and these requirements and include those at Scope, then something’s going to be pushed out of Scope, right. Because overall, we’re trying to hold the Scope to the hundred Story Points that we started with as our baseline. They understand that, they understand that they’ve got to … you know, in order to include something new in Scope, they’ve got to kind of push something out to a lower priority. Maybe if we operate faster than we thought we would, and maybe if we get more work done than we thought we would originally planned, we could still do those original stories. But in some cases you can’t, and that’s when things actually get moved out of Scope.
The other choice the customer has, Danny, in that scenario where we’ve uncovered new requirements and we’ve kind of shared with them what those are, what the impact is in the way of size, which also impacts Schedule and Budget. The other option they have is to say these new requirements are important, and there’s nothing I can move out of Scope. I still need to have everything you originally stated, plus these new requirements are important to me. In that case, that would lead us to create a [inaudible 00:14:59] with that customer. We would expand the Scope, which then would impact Budget and Schedule. The beauty of it is, we’re doing that every two weeks.
Danny Ryan: Yes.
Bruce Harple: We’re constantly in that expect and adapt kind of principle behind Agile. You are constantly looking at where am I today, what did I get accomplished in this last Sprint, what else new did I learn that’s impacting my Scope, what the User Stories have identified, and what do we want to do about that. We don’t want to ignore it, we want to recognize that we’ve uncovered new requirements and they’re valid. They’re important to the customer. We then together decide how do we incorporate and include those new requirements in the project.
Danny Ryan: We typically … for the back to the statements of work, will typically write the statement of work around a time and materials budget, not to exceed a certain amount, right? So we write it up that way, and then if we see that there’s things that they want to pull in that would exceed that amount, that’s where we would talk through the change order, we need that additional. But yet let them make the decision as far as whether those new features need to be included or not.
Bruce Harple: That’s right. In some cases, we are actually ahead of our original plan. In other words, if our velocity, the rate at which we can implement a Story Point is faster than we planned originally. Maybe we’re better and more efficient. Or maybe we found some ways to implement some Stories that were simpler than we assumed when we did our original estimate. It could be that we’re kind of ahead of plan and ahead of budget, and we can actually take in additional User Stories and not impact the original budget or timeline. That happens in many cases.
Danny Ryan: You do that way too much, Bruce. Really, really. I am amazed that just internally I know we look at from a planning perspective, if the SOW is at let’s say one hundred K, we’re planning to really to hit below that, more like eighty K, because we’re typically delivering the solution to people. Not to over-set expectations, but it just seems like we have the ability to manage to that budget and give something to someone that they really want under that budget. That’s really, really important to customers.
Bruce Harple: Yes. It is and that’s one of the things that they like about Agile because they are seeing features delivered to them, put in their environment, right. So they can actually do their UAT testing early on as they go. You’re constantly looking at the Budget and the Scope every two weeks. You’ve got that such a great view into where you’re at and whether you’re ahead of what you thought or behind. You get to make those adjustments every two weeks, which is really important to customers. They really love that.
Danny Ryan: That’s awesome. I just wanted to wrap us up here. This has been a great conversation. I think we can talk for hours here. But I know one of the things that we’ve come up with through the years was the ThreeWill Promise, which we’ve talked about internally quite a bit where the three C’s, Control, Choice and Commitment. I think that what we’re talking about today really have to deal with those things with Control, we say that we provide the structure for clients to control Priority of Features and Budget throughout the lifetime of the project.
How important is that? How important is it for the client to maintain Control? Choice, because we’re delivering it every two weeks, we’re earning business every two weeks as well. We’re delivering software every two weeks. The great team that you’ve put together, Bruce, out there delivering every single day. The last one is Commitment. It’s where people are really taking on the Challenges, like their own Challenges. I love how committed we are to clients. You guys just do wonderful job. It’s so much fun talking to clients after we’re done with projects and hearing what’s been done. So I appreciate you, Bruce, taking the time. Any thoughts to wrap this up at all? Anything you want to add?
Bruce Harple: No. Just that we really enjoy working with our clients. I think they enjoy our process and the way we attack these problems. I think they appreciate the Agile process that we bring to bear. It’s often, there’s plenty of days one of the things customers call out when we do surveys with them and try to understand their level of satisfaction with ThreeWill. It’s one of the things they typically call out as one of the things that they see as one of our strengths, and that they really appreciate.
Danny Ryan: Yes. I think it’s … I hear a lot from people that the original reason why they brought us in was because of our technical experience, and then the reason why we stay around and why they want more projects from us is because of our process, because of what they see delivered on projects, which is wonderful. Wonderful to hear.
Bruce Harple: Absolutely.
Danny Ryan: Hopefully if you’ve gotten to the end of this Podcast, thank you for taking the time to do that. If you are a perspective client and hopefully some of this has helped you out a little bit, or a current client. Really, the whole estimation process, getting a handle on how much time it’s going to take, how much the cost is going to take. That is part of what we do, that’s a part of our sales process. I highly encourage you to come to our website. Reach out to us. We’ll put together the details so that you can really put together a sound Budget and something that’s workable. Please feel free to reach out to us. You’ll interact with myself and Bruce, and folks from his team. It’s a great process that we’ve put together here. Bruce, thank you for taking the time to do this.
Bruce Harple: Thank you, Danny. I enjoyed it.
Danny Ryan: You bet ‘cha. Have a great day. Thanks everybody for listening. Bye bye.