Archive for the ‘Customers’ Category
When I talk about estimation and planning, people often ask me the above question. The styles of estimating I talk about are more frequently used in a non-agency environment, that is, somewhere maintaining a single, existing product, or creating one, for your own company from scratch instead of the agency method which delivers software per project, per client.
The problem with this kind of work is that of estimates. Typically, as an agency, you’ll be bidding or pitching to a client to get the work. The client will probably be soliciting bids from multiple agencies, so you need to either stand out from the crowd in some way, or be the cheapest (or, preferably, both).
The client will generally be looking for a fixed price too, this is so they can go back to whoever is commissioning the work and get funding, or raise a PO or whatever.
Sometimes you’ll be given a brief, which you might then turn into a functional and/or technical spec, which then goes to the client along with the quote, then there’s some to-ing and fro-ing, an agreement and then work commences and oh shit, we forgot to add the widget to the spec and oh crap we underestimated the amount of data we’d need to use and have to re-engineer to use mongodb.
So, with this in mind, how do you estimate, quote, pitch or bid when agile methods are so fluid and you have to work to a fixed cost? You know the least about how long a project will take and what is involved right at the beginning. Using the Cone of Uncertainty, you’ll be between 4x and 0.5x inaccurate with your estimate of an end date (eg: at the beginning of a project that you estimate takes a month, it could take between four months and two weeks)?
There’s a few metrics you’ll need in order to derive costs from estimates:
- Day Rate: How much a team costs per day. This is only ever going to be a rule of thumb (as there are holiday, illness, training etc.). But you should make it as accurate as possible. This becomes a key metric in working out costs from estimates. You should make sure that your client understands that for the purposes of estimating and pitching, this is an accurate, but rough figure.
- Best, worst and average velocity: these are important metrics. Your average velocity is simple, add all your sprint velocities together and divide by the number of sprints. You could make this more realistic by using a rolling four sprint velocity, this then takes into account changes in team size, tooling or process. However, for the purposes of estimating the cost of project up front, the average will do.
The best and worst velocities are derived by taking an average of your three most successful sprints and the three least successful sprints. Why you need these will become clear later.
Should you have multiple teams and you’re not sure which team will be working on your project, then take an average across all the teams.
Honesty and transparency
The fundamental tenet in any of these below strategies is complete honesty and transparency with your client. You’ll also need to invest three or four days (maybe less, it will depend on how practiced you are at this process, it will become quicker) in your client, it might sound like a lot and there is a risk there might not be a contract at the end of it, but it is worth it. Once you’ve deeply involved your client in the process from the start, they’ll feel like they’ve already started the project and so it’s easy for them to transition to being a paying customer.
From the outset, you’ll need to explain that you do things a little differently to other agencies. Whatever framework you choose to use (scrum, kanban, etc), spend some time explaining to the client what it is, how it works and why you use it. If you’re a little stuck, here are some ideas
- It gives you a realistic view of the progress and scope of the project.
- It gives you, as the client and stakeholder, complete control over what features make it into the final product and which don’t.
- It allows us to deploy features to live as soon as we’re ready to, meaning you can be getting value from our work and your product, even before we’ve finished it.
- These early and frequent deployments allow you to test your assumptions about your own users and customers and, if necessary, change the features or product without additional cost.
- You will be encouraged to be involved throughout the whole lifecycle of the project and can view each separate feature as soon as it’s finished to help guide and steer the project toward exactly what you want (which might not be what you originally asked for).
The best way to do this is to invite your client in for a half-day, high level training and workshop. Run some exercises to illustrate the key points and answer all their queries – this is a new thing for many companies who aren’t used to this kind of agile environment, so it’s definitely worth introducing your client to it if they haven’t experienced it before.
The next step is to create some artifacts. Once you have a brief in hand and have spent some time with your product team and analysts and have a really good understanding of the brief, the market, the competitors etc, invite the client in again in order to build a product backlog of user stories. Set the scene for them and explain that, unlike other agencies, you won’t write a functional spec, or a technical spec, because they’re a waste of time. What you will do is write user stories, which describe each feature from the users’ point of view and what value each of the stories will bring.
Labour the point too. Ensure your client *really* understands that you won’t be building ANYTHING that you can’t find the value for and WHY you take that stance. If a feature, or some functionality, has no value, then why would you build it?
Work quickly through the brief and your research and build a backlog of epics with your client. Don’t spend longer than an hour or two on this and, if you have somebody, get someone to facilitate the meeting so you don’t get bogged down in ANY technicalities, or discussions that are long or drawn out. Once you’ve got your list of epics, have the client order them – which are the highest priority things? What user/customer value do they want to deliver first? Don’t worry about dependencies right now, this is only rough.
Finally, break the highest priority epic into a few slightly smaller stories. This isn’t strictly necessary, but will help the client understand the process better. Again, this shouldn’t take longer than 30 mins.
The estimate and the pitch.
Now you’ve got your feature list of epics and some smaller stories for the highest priority, get some estimating done. I won’t cover it here, but you can read the article on white elephant estimating, or watch my presentation on agile estimation. Try and use the team that will actually be doing the work. If you haven’t got a team, or not sure which of your teams will be doing it, then pick engineers, designers and QAs from multiple teams – you’re only looking for roughly accurate figures. If it’s proving too difficult because of the epics, then break some into smaller stories – getting epics and stories sized well enough to estimate will become easier with practice.
Finally, you’re in a position to pitch, but how do you do it? It all depends on your clients requirements.
It’s very important that the client understands they have complete control over what goes into their product on a sprint-by-sprint basis. Explain that you expect them to be involved in the decision making about what goes into the product, the priority of the features to be added and the scope. So, once you’ve agreed on one of the below strategies and signed a contract, the success of the project will be partially down to their input.
If your client requires the project to be finished by a certain time, you can work towards that. It will be to your advantage to provide two estimates though, allowing the client to choose their own end goal:
All stories by the deadline
Estimate the number of teams or people required to deliver all the story points by teh date, then, based on a day rate, create a figure. Remember, to be accurate (but not specific), you’ll need to provide a range, so, using your best, worst and average velocity you can say to your client, “We ESTIMATE, it will take four months, but it could take up to five and half, but it could take three months, therefore, it will cost between £40,000 and £55,000″.
A valuable, shippable product by the deadline.
Do the same as above, but use a fixed sized team – you won’t be able to fit some stories in, but this is fine. Use the average, best, worst to show the client the stories you will definitely do, you will probably do, you might do and you won’t be able to do. This will reduce the scope of the project, but also the cost. Remind the client that what features make it into the product is based on their input.
Working towards a fixed cost is quite rare, but does happen and it will likely mean that the client won’t be able to have all the features they’ve asked for. In order to work towards a fixed cost, you need to know it (obviously…). Once your client has offered this, you can use it to work out your strategy. It will be similar to working out a fixed deadline. You know how long you have to deliver the project based on the day rate (fixed cost / day rate = number of days). So, then you have a fixed deadline to work to and can use the average, worst, best strategy again to indicate what you can definitely achieve, what you can probably achieve and what you definitely won’t achieve.
Finally, there is fixed scope. The client has to have everything they’ve asked for – in practice, during the project, this is rarely true once you start building and the early, regular releases helps steer the project.
Again, using your best, worst and average velocity, you can work out a range of how long it will take and then use your day rate to provide a figure.
Cost per iteration
(I wouldn’t suggest this method unless your client is particularly agreeable to trying new things, but, assuming you did the setup correctly I describe above, then they should be chomping at the bit to try this new, visible, transparent and honest method of commissioning software)
Pitch at a cost per iteration, instead of a day rate. You can give rough estimates on how much it will cost and these will become clearer after each iteration. Pitch for a minimum number of iterations after which your velocity will stabilize and you can be more accurate in the remaining length of the project. This is a fairly ambiguous method of pitching though, you’ll need to draw on the other strategies above to work out what features and functionality can be delivered, but if your client agrees to sign you for a minimum number of iterations, and you deliver what you agreed to, by this time, your estimates should be pretty accurate and your velocity very stable, allowing you to accurately cost any stories you haven’t managed to complete.
Honesty and transparency, again.
It’s worth reiterating here that you should be completely honest with your clients as to how complicated and amorphous quoting for a software project is. If you think your client can understand it, then break out the cone of uncertainty to explain that 40 years worth of data prove it to be true.
Explain that, being agile and adopting a framework to allow for short, deliverable cycles allowing for fast-feedback means that your company will very quickly start delivering visible value to them. It will also mean that they can control what that value is on an iteration-by-iteration basis. But, probably the best arrow in your quiver is to explain that, throughout the project, they can see the progress on an almost daily basis and adjust both what you deliver and how much they want to pay you should they need to.
If you deliver some valuable piece of software that causes them to change they way they think about their product, then they could pivot their entire offering and find more funding – and who is already in place to help them achieve that?
Hooray! We won the contract!
Congratulations! Now, don’t sit on your laurels. Remember the commitments you made to your clients during the pitch process and keep them involved through the project. Begin with release planning to decompose the epics into more usable stories and begin to uncover more of the project as you go, with milestones and deadlines if necessary. Keep your client informed, involved and in-the-loop and they’ll be happy when things change (and they will).
Boo, we didn’t win the contract.
Sorry, that sucks – but use it to learn a lesson. Find out why you didn’t win. If it’s just down to cost, then perhaps review your costs, or spend more time breaking down and estimating the stories to provide a more accurate figure next time.
Send out a survey to the client, asking them what they thought of the process and whether there is anything they’d change, or something they didn’t like. Gather as much data as possible, then spend some time retrospecting with your teams about how you can do it better next time.
My client doesn’t want to be that involved or isn’t interested in how we do it.
My advice here would be to not take on the business. If your client isn’t interested in being part of the process of building their product, then you are setting yourself up to fail. You’ll deliver a functional and technical spec detailing exactly what they want, you’ll deliver it and then find out that, while you delivered what they asked for, it isn’t what they wanted.
The old black box model of estimating and pitching for client work is difficult to manage, hard to sell and will bite you in the ass later down the line if you got it wrong at the start. By getting your client on board and understanding how you do things, and that they can and should be involved from the beginning to the end, you put yourself, your company, your team and, importantly, your client in a position to succeed.
Henry Ford is quoted as saying “If I’d asked my customers what they wanted, they would have asked for a faster horse!”. While this might be true, this is a short sighted view of product management.
Often, our customers will ask us for something they want, but they’ll frame it in the context of something they already have. This seems to them to be the right thing to do. It’s helping us out as the people who build their products, right? Kind of. If we were to take the view that customers always know what they want, then I suppose so. However, our customers will endeavour to give us a solution to the problem they have, instead of being clear about their problem and letting the problem solvers have at it instead.
If your customer says “I want to be able to send an email to all my users informing them of X,Y and Z.”, You’d think they what they wanted to do was send an email to customers about X, Y and Z. But is that what they really want?
If you probe a little deeper, by asking open questions, you might find a different answer:
“What is X, Y and Z?”, you ask.
“Well, it’s the new promotions we offer, we want to tell our users about them as they might not find them in the promotion list.” Replies your customer.
“How does the promotion list currently show them?” you probe.
“It’s ordered with the newest on top, but if our customers aren’t looking for promotions, they might miss them.”
“So, you need a way of highlighting your newest promotions?”
“Yeah, I guess so. But we’d like to be able to send them emails about other things as well, like changes to our terms, or new features.”
“OK, so am I right in saying you need some way of informing your customers of new features, promotions and other pertinent information?”
Now you have the real problem, which turns out to have little to do with email and there are many ways to solve this kind of problem. It’s now a case of discussing these ideas further with the customer and the team in order to find the right solution … which might not be a complex email system.
So, if Henry Ford had asked his customers: “What do you want?” and they said “A faster horse!”, he might have asked, “What do you need a faster horse for?” and the answer might well have been, “Duhh! To go faster!” Which is the real requirement. One that he fulfilled quite well.