Archive for the ‘Estimating/Planning’ Category
How to estimate, pitch for and charge for a project in an agency enviroment
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
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)?
Some metrics
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.
If you don’t have this data, you have two options: guesstimate, or use the cone of uncertainty.
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.
Fixed deadline
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.
Fixed cost
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.
Fixed scope
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.
Using your average, best and worst velocity to predict a schedule
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.
Finally
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.
Estimating stories quickly and efficiently with ‘The Rules’
ticktickticktickBING - An Old Timer by hiro008 on Flickr
Estimating a backlog should be easy, especially if your Product Owner has looked after it, knows how to write good stories that mean something to the developers and the business and is able to prioritize based on business value (or, customer delight!). However, estimation meetings, poker planning, planning two or whatever you call it, can often be painful events that descend into chaos, anarchy and heated debate. While these things are all fun, estimation should be fast and simple, afterall applying arbitrary numbers, whose only measure is relatively sized, to amorphous items of work can’t be rocket science, so why would you want to spend much time on it?
Trouble is, developers and engineers are paid to solve problems, that’s what they love to do, so they begin the moment the problem is presented! This is to be applauded, but doesn’t really nail what should be fast conversations about stories!
We’ve recently been coarse estimating the next releases’ worth of stories for each if our products, the backlogs for these products contain between eight and 38 stories, depending on the goal. When we started estimating these, it was clear that it was going to be painful, so I created ‘The Rules’ (to be clear, they’re guidelines, remember the Shu Ha Ri!):
- Reset the countdown timer to five minutes.
- Product Owner reads story and acceptance criteria.
- Team ask questions to clarify their understanding of the feature. No technical discussion.
- When no more questions, the team estimates.
- If estimates converge or there is consensus, GOTO 1 and start a new story.
- If no consensus, start more discussion. Technical discussion is OK here.
- When the conversation dries up, or the time ends, whichever is first, the team estimates again.
- If estimates converge or there is consensus, GOTO 1 and start a new story.
- If a consensus isn’t reached, reset the time for another five minutes.
- When the conversation dries up, or the time ends, whichever is first, the team estimates again.
- If a consensus still hasn’t been reached after 10 minutes, put a question mark next to the story and GOTO 1 and start a new story.
- Optionally: create a spike story to discover more information in order to estimate the difficult story.
You don’t really want a faster horse!
Horses, going slowly. Photo by The Library of Congress - http://flic.kr/p/a88fYb
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?”
“Yes!”
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.
The Definition of Ready
Well, I’ve only gone and got myself published on the Agile Journal! Here is what I had to say:—–
Are you ready? Image by Kevin Dooley on Flickr
Development teams use the idea of a definition of done (DoD) to decide when they think a user story is ready to be shown to the stakeholder for review. The DoD is like a bouncer or doorman, ticking technical criteria off on a list before the story is allowed in to party. The DoD is a powerful tool, and while its explicit value is obvious in ensuring the quality of a user story before review, its implicit value is equally, if not more, important. The DoD forms a contract between the development team and the product owner (PO). This contract not only ensures that stories meet a baseline of quality but it also creates a bond of trust. The PO knows that, with a DoD, he can trust the team to deliver a quality technical solution, and in agile software development, trust is key to your success. The acceptance criteria form a similar bond between the PO and the stakeholder or business. The criteria are designed to help a PO decide if a story meets the stakeholder’s requirements. It’s this list—defined in conjunction with the stakeholder—that creates trust on the stakeholder’s side. They know that their PO will deliver what they need, because it says so on the story. The DoD and the acceptance criteria combine to make a powerful ally for your team’s success. But both of these things require that the user story itself is sensibly written and defined and that the acceptance criteria aren’t some magical pie-in-the-sky, moon-on-a-stick list of ridiculous demands that would give a hostage negotiator nightmares! The PO can make use of a similar DoD called the definition of ready (DoR). This can be used for all the same reasons the DoD is used for the team. It’s useful if the Scrum team helps the PO come up with a DoR, help her define things about stories that make them easy to understand:
- small enough to be manageable in a sprint
- contain enough detail to estimate accurately and
- create acceptance criteria that really help define “done.”
POs don’t just pluck an idea out of the air, write a user story, and drop it onto the backlog (we hope). Stories go through a process just like the software they drive does. The PO has a responsibility to the team to create user stories for them to estimate and, at some stage, work on, that aren’t badly defined or not thought through. Team members don’t want to have to do a bunch of the PO’s work in order for them do their own work and deliver value. To this end, a PO and the Scrum team might find the DoR useful. This is a contract that the PO has with the team in order to say “Before I put a story in front of you, I will have done everything I can do make it not suck.” Some examples of criteria on a DoR are:
- Story contains actors, problem, and value
- Story should fit in a sprint
- Story should be appropriately documented (does it require wireframes? User-journeys?)
- Value should be obvious, if not, it should be explicitly stated
- Story should have reasonable conditions of satisfaction
- Story should focus on problems, not solutions
Using the above example, we could ensure that the user story: Show users other products that they can buy before they checkout which begins life as a throwaway request from a stakeholder at an audio-visual online storecan be rewritten using the DoR as: As a customer, I would like to see products that I might like to buy at the same time as my television, hi-fi, or other product, so that I can be certain I have everything I need. Acceptance Criteria:
- Show users products that other customers, purchasing the same products as this user has chosen, have bought also
- Based on what the user has added to his basket, show him products that could potentially be used with it, e.g., if he has chosen a TV, then show him cables, TV stands, and Blu-Ray players
- Show ratings and percentage of customers who ended up adding the additional products to their basket.
This shows the actor, problem, and value for the customer. The value for the business is implicit in that it will increase uplift. The story is appropriately documented with reasonable acceptance criteria, however it doesn’t tell the developers how it should be done technically. I’m a big fan of release planning meetings. These meetings include going over the team’s DoD to see if there are any changes team members want to make in conjunction with the PO or stakeholders before they start sprinting. This is an ideal time to create your DoR as well. In addition to the explicit value you get from having a contract between the Scrum team and the PO, the DoR also goes a long way to fostering trust (as long as the PO follows through) in the same way that the DoD and the acceptance criteria do. If you have a bad sprint, during the retrospective, you can review your DoD and your DoR. Did the story require more work before it went into the sprint backlog? The DoR provides a similar yardstick to that of the DoD when looking for root causes of failure. Try adding a DoR to your process, especially if you’re having trouble with your stories being difficult to estimate or work on. You’ll reap benefits immediately, building trust and creating stories that have real value.
Failing sprints? Decompose your stories to the nth degree
Is he about to fail his sprint? Image by Sebastian Mary
Recently I had a retrospective with one of my teams after two failed sprints. They cited unplanned tasks as one of their issues and suggested that perhaps the scrum framework wasn’t right for the kind of project they’re currently doing.
To give some context, this is a long running team on a long running project with no kind of release windows. One mistake that we did make was that there wasn’t a ‘Sprint Zero’; a chance to look at the project as a whole and do some time-boxed up front planning for a sprint. However, we’ve entered two sprints without some knowledge of how we plan to do things and it’s caused bad sprints.
When we began to plan the current sprint. There were some ‘technical’ stories in the backlog, for large chunks of backend work which had other stories dependent on them. They were all estimated quite high, without acceptance criteria or the ‘As a …, I need …, so that … .’ stanza to support them. This is fine, the stanza is only important when it provides value and usually not for technical stories. One of the problems was not having acceptance criteria, so the first thing we did was to define those.
After that and to get to the crux of the post though, I asked :
Describe this story in high-level steps.
To which the team discussed what would be done to do each story, we defined the tasks at a high level (much like you would do when planning proper), but after each task was defined, I asked the team to estimate the tasks in story points. It was an eye-opener!
The tasks were all coming in with estimates of 2′s and 3′s. Which meant that, when the broken down, estimated tasks were added up, they were more than the original story. This usually happens, but it was an ‘Ahha!’ moment for the team. It allowed them to think more abstractly about the work. It’s not the plans that are valuable, but the planning!
To compound the issue, we’ve been getting hung up on the idea of each story delivering functionality which we can demo. While this is a noble goal, I’m sure it’s not always possible. This was causing huge estimates on stories and, as we know, bigger estimates mean lower accuracy on that estimate. With this constraint removed, the team breathed a sigh of relief and began writing stories which were meaningful and well sized. What actually came out of it is that, once we’d broken them down, we could see that for some of them, there actually were things we could demo; speed improvements on database queries and data integrity which DO provide value and so can be demoed.
Finally, when choosing the stories to add to the sprint, the team committed to work which they used their gut feel (and their velocity, but only as a guide) on what they could fit in. I went through each story asking, ‘Can we do this and all the previous stories?’ They committed to less than they would have had they just added the original stories. Meaning that, the non-decomposed stories were causing them to overcommit without recognising it.
So, if you’re failing sprints due to unplanned work cropping up and causing you to have over-committed, then ask for high level tasks on how to complete the story and estimate each of these tasks as if it were a story, you can go too far by decomposing each task to a story level, but if you’re finding this is the case, then your failed sprints probably aren’t caused by your stories.
Adding a timeline to your sprint backlog
I like retrospectives, actually, I love retrospectives. Especially retrospectives that really get to the root of any problems the team are having and then get a great solution or at least something to try. The trouble is, retrospectives can often be stale, how many times have you been in a retrospective and had this:
So, um, yeah, good sprint, I think everything went well, didn’t it? I had a problem with some testing, but I fixed it. What was it? I can’t remember. Something to do with fixtures, but it got done.
The problem with memories is that they’re fallible. Who can remember what you did two days ago, let alone a week ago. Certainly me and, it appears, neither can the teams I coach. There are things, you can do to make retrospectives better, but this wasn’t so much a problem with the retrospective as a problem with memory. So, what did the teams do? Added a timeline to their sprint backlog. It’s quite simple really. Create a grid on the bottom and, in every standup, discuss whether anything happened yesterday that could be added to the board. The idea is to get key things on there, so, stuff that went wrong, stuff you noticed or learnt, good stuff; use it as a way to remember the timeline of the sprint. When you get to the retrospective, you’ll then have an entirely different conversation than the one above.
Timelines FTW
Some of the teams have gone a step further and added an arrow to remind them which day of the sprint it is and even added holidays/absences. What do your teams do to remember their iteration?
Timeboxes, more than just a buzzword?
Little Baby Timebox! - Image by sⓘndy°
I read in my twitter stream today, this from @lloydwatkin:
lloydwatkin
I really hate bullshit phrases used in tech, my latest word of hate is ‘timebox’
04/05/2011 15:16
and it got me thinking about time boxes. I use the word a lot and use the concept of time boxes in almost everything I do and Lloyds comment made me think “is this just a bullshit idea, or just a bullshit word, or bullshit in general?”
When meetings suck
I don’t know about you, but I’ve sat in my fair share of meetings that totally sucked. No one really had much to say, the conversation goes off on tangents, someone announces that we can’t talk about that now as it’s part of a ‘series of conversations that we need to have’ and everyone inwardly groans. There’s no agenda, no action points … nothing. Usually one person will dominate the room, quacking on as if they love the sound of their own voice, making statements based on little more than opinion, causing everyone in the room to raise an eyebrow and, maybe, an eye from their game of Angry Birds under the table. People pretend to take notes on their pads on their knees, when really they’re drawing larger and larger concentric circles and colouring every other one in while perhaps writing a poem, or ode to boredom*.
These are the meetings that everyone hates, when there are too many people, no agenda and people prone to waffling about shit only 20% of the room understand or care about. How does time boxing help here?
An agenda is a time box. If you’re booking or facilitating the meeting, you’ll find that an agenda and the authority to chair the meeting are all you need to have a successful outcome (assuming you have an idea of what the outcome should be). When you book the meeting, set the agenda in the meeting request:
00 – 10mins – Welcome and introduction
10 – 20mins – Talking about the herping
20 – 30mins – A demonstration of the derpa-machine
30 – 40mins – The future of the thing
40 – 60mins – Q&A, action points and AOB
These are time boxes. Maybe you don’t call them that. Most people call them agenda points and many people will leave off the timings, but by adding the time boxes to it, you’re subconsciously telling the attendees that, unless something extra happens, this is what we’ll discuss and this is how long you can expect it to take. If 50% of your attendees don’t care about the herping and 50% don’t care about the derpa machine, then those people know exactly how long they can draw concentric circles or play angry birds for. Or, they’ll know they only need to give 10mins attention to something they’re uninterested in and that’s better than 60mins attention to find the 10mins you’re interested in. Doing an agenda will also give people time to think about what they should be doing to prepare for any, all or just their part of the meeting. Finally, by setting a perimeter around an acceptable length of discussion time gives you the authority to say: “OK, we’ve run out of time for that agenda point. Batman and Spiderman, if you have more to say on this matter, please book another meeting and invite those people relevant. OK, so onto the next point…”. Trust me, people will be relieved.
So, by simply adding some timings to your agenda (which we can agree are useful) you’ve created time boxes. Things look good for time boxes so far.
What about meetings that can’t have an agenda?
Well, some meetings can’t. In SCRUM there are two that definitely don’t have any kind of official agenda; retrospective and sprint planning. Retrospective is a meeting where the team discusses HOW they did the work in the last sprint and what could be done to make it better. Generally, this involves everyone taking turns to say what they though was good, bad and how they think it might improve. Timeboxing here lends itself well in that, you divide the length of the meeting (in minutes) by the number of people and that’s how long each person get’s to speak for. They’re each time boxed. If there are six people retrospecting for an hour, they get 10 minutes each.
As for sprint planning, you can do the same with each section and then the stories. You’ll have to play with timings, but I suggest:
00 – 10mins – Cocking around that devs do getting coffees etc.
10 – 3omins- Quick groom of the backlog
30 – 60mins – Work out velocity and commit to stories
60 – 240mins – This is where it get’s fuzzy. It all depends on how many stories you’ve committed to. If you’ve committed to, say, three. Then divide the remaining time by three and get on with it. If it’s many stories, then perhaps set aside 45mins for the first story, 30mins for the second and 20 mins for the rest. Remember, you don’t have to do all your planning up front!
So, score two for time boxes. Without time boxes, sprint planning would but much harder and probably longer. Besides, they’re also one of the basic rules of scrum!
But that’s not all…
When scope creeps
![Col. C.B. Winders [i.e., Winder] (LOC)](http://farm3.static.flickr.com/2349/2162738187_ce0b133a3b_m.jpg "Col. C.B. Winders [i.e., Winder] (LOC)")
Mah Scope Don't Creep Suh! - Image by the Library of Congress
If you’ve been in software or web development, you’ll have been a victim of scope creep. You get the list, you work your way through it and, all of a sudden, you’ve run out of time.
“But wait, ” you say, “surely time boxes cause this ‘lack of time’ problem.” Well, yes and no, but they definitely provide you with a reason NOT to do the stuff that has crept out of scope. Scrum is based around the idea of time boxes. Without them there wouldn’t be iterations. An iteration, or a sprint, is a timebox. Sprints don’t get extended, or shortened (although they can be cancelled). At the beginning of a sprint, the team commits to a bunch of stories that the product owner wants done. They work on them and, when nearly finished, will show the product owner or stakeholder who might say “Hey, that’s nice, but can you…” . To which you answer…
“… No, but if you wait unti the end of the sprint and ask me, I’ll do it then.”
Anybody reasonable can see that it’s a good compromise: work has been asked for that is clearly out of scope. The developer doesn’t have time to work on it during this timebox, but the timebox is there, defined and immutable, therefore can be used placeholder for when the work CAN be done (apart from the fact that the extra work needs a user story and estimation and prioritisation etc) and the stakeholder or product owner only has to wait until the end of the sprint (the maximum wait will be two weeks). Usually, by that time, they decide it’s not a relevant change anymore, or it was so insignificant as to be forgotten.
The point is, it’s there to add some boundaries, to protect the developers from scope creep and to protect the stakeholder from adding work that isn’t well thought out or valuable (this is quite a simplistic view, but it proves the point of the value of time boxes. Obviously, lot’s more comes from the scrum framework in order to derive value, but out of the scope (fnarrr!) of this article).
Right, so that’s three for three … next!
When the kitchen is a mess
So, when I said I use time boxes in almost everything I do, I meant it. I mean even my personal life and I suspect you do too (even you @lloydwatkin!). As an example which is fresh in my mind from last night: I was tidying the kitchen and had set myself some time boxes: 10mins to wash up, 5 mins to clear and clean the table, 5 mins to sweep the floor and 10 mins for extra stuff — 30 mins to clean the kitchen.
With these time boxes set for myself, it become a challenge to get this stuff done in those time boxes. And lo and behold, it takes 30 mins to do a chore which might otherwise take me an hour and a half (most of which would be procrastination). It also stops me from doing too-much-work (K.I.S.S!) as I might put something in a cupboard and think “Hmmz, that cupboard is a mess, I’ll just give it a quick tidy.”, et voila, scope creep.
Finally, time boxes aid immensely with parenting. If you’re a parent you’ve probably said (or shouted): “10minutes until bedtime!” and this creates an unwritten expectation (much like the meeting agenda or the sprint length) that, at the end of 10 mins, some action will happen (bedtime). Instead of the ambiguous “Bedtime soon!” which leaves it open ended and easy to abuse.
What to avoid
Boyles law states:
For a fixed amount of an ideal gas kept at a fixed temperature, P [pressure] and V [volume] are inversely proportional (while one doubles, the other halves). – Wikipedia
Which means, gas will expand to fill available volume. This law can also be used to describe development:
For a fixed amount of ideal developers kept saturated in caffeine, velocity and time are inversely proportional.
Which means, work will expand to fill the time allocated to it.
This is not always true, but you should be wary of it. Some teams will feel that, they have two weeks, so they can take it easy if they’ve underestimated a story or two. This is not fine. Velocity should remain constant. If at any point your teams feel they have undercommitted, then commit to more, or do something with value to the team – rebuild a tool, or refactor some code or SOMETHING and perhaps next time, commit to a little bit more and see if you can stretch a bit further. It’s a limbering excercise.
A time box is a limit, not a goal. If you’ve got a 10 minute time box in a meeting, or elsewhere, you don’t have to fill it, you just have to have finished within that time box.
How do I estimate how long an agile project will take, before we start?
Elephant Black and White
I was asked this a while ago and I’ve seen it mentioned a few times on blogs and forums and what not. I’ve answered it on a few occasions, so I thought I’d put it all into a coherent blog post.
Estimating a project before you start, with a brand new team is a tricky situation and one lots of people encounter.
There is a way you can work it out though, but your product manager should understand that it’s an estimate and it will change. If you need some backup, read this article on the ‘Cone of Uncertainty’ by Jeff Atwood and remember, you know the LEAST about a project right at the beginning!
How can I estimate?
There’s two ways you can do this; based on points or based on hours. I’d suggest using the hours method as it will give you a range. You can get a range with points as well, but only when you’ve done a few sprints. Some people are against estimating in hours and, usually, I am too. But for this “beginning of a project with a new team” exercise, it’s invaluable. The below all assumes that you have a product backlog ordered by priority.
I’ll start with the points method (and, step 1!):
- Estimate, in story points, your entire backlog. This is easier than you think and is often called the white elephant method, we use it with great success.
- Draw up somewhere a grid with 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 and ? as labels.
- Print out all your stories, or, if you’re already using index cards, just put them in a pile (but remember to put their priority order on them, so you don’t forget!) and put them in a stack somewhere.
- Now, each member of the team gets up, picks a story from the pile and sticks it to the board where they think it goes. If they have NO idea, then they put it in the ? box.
- Get everyone in the team to take turns in doing this. They must all do it in silence. Each turn they can pick up a story and place it on a board, they can also move a story that is already on the board, but they have to pick it up, face the team and say ‘I am moving this story because… ‘, then they can re-place it on the board.
- This goes on until all the stories are gone from the pile and no one is moving stories anymore.
- If you get two people moving a story back and forth because of a personal belief on it’s size, just have them put it in the larger number.
- Now, pick the story at the top of the backlog and say “Can we do this in two weeks?” If the team says yes, put it on the board, this board represents your sprint. Pick the next story and say “Can we also fit this story into two weeks?” if yes, put it on the board. Continue until your sprint is full.
Now, assuming you’ve story pointed all your backlog and the total is 260 points, you’ve worked out you can do 20 points per sprint, that means it’ll take you 13 sprints based on story points (so, 26 weeks). This will be quite wrong, but will give you a rough idea. If your product manager is bit simple, he might start telling everyone it’ll be done in 26 weeks. So, do the next step too:
- Ask each member of the team to estimate a max and min number of hours a day that they can work (taking into account meetings, phonecalls, emails etc etc that take time out of your productive, development hours); so Steve might say 4 – 5, Tina 5 – 6 and Hardeep 6 – 7. Work this out as hours per sprint. (So, Steve can do 40-60 hours per sprint in a two week sprint), with the above figures you’ll have a range of 150-180 hours a week;
- Remove all the cards from the board and put them back on the backlog;
- Pick the top story again, say “Can we fit this into a sprint?” If the team says yes, put it on the board again;
- Next, break this story down into tasks and estimate those tasks in hours;
- Do steps 3 and 4 until the team says they can’t fit anymore in the sprint based on the total number of hours (by adding up all the tasks) and their estimated man hours per sprint (ie: 150-180 hours per week as above), as a guideline, you should probably stop at around the 165 hour mark or, if the team cannot agree whether a story would fit or not, assume it won’t;
- Add up the number of hours they estimated, now you have how many hours they can fit into a sprint;
- Add up the story points for the sprint, this gives you your velocity.
So, you now do:
> total story points / velocity (from step1) = number of sprints based on velocity (don’t use this though, it’s a very rough guide)
> number of sprints based on velocity x (estimated hours for sprint (from step 2)) = total hours for project.
and then:
> (total hours for project) / (lower weekly hours estimate) = minimum number of sprints
> (total hours for project) / (upper weekly hours estimate) = maximum number or sprints
As an example:
> 400 / 20 = 20
> 20 x 165 = 3300
> 3300 / 150 = 22 sprints
> 3300/ 180 = 18 sprints
So, now you can say to your product manager, the project will take between 44 and 36 weeks (assuming two week sprints). Again, this is still only an estimate, but it gives you a better idea. Especially as you know the least right at the start. The best thing to do is provide continual updates to the PM. Once you’ve done a couple of sprints, you’ll have a better idea of your velocity and you should groom your backlog frequently (including re-estimating occasionally) to keep your estimated delivery fresh, based on the most up-to-date knowledge.
Resourcing, it's just an estimate OK?
Reign of the Supermen by fengschwing
Too often, businesses seem to think that the resourcing we do during sprint planning to work out how many ideal hours we have, allowing us to decide what we can fit into a sprint, is an accurate reflection of how much work the team can/will do.
It’s not, OK, chill out. At BEST it’s a worse case scenario.
The average work day is 7.5 hours. That does not mean that I can dedicate 7.5 hours of work to tasks from the board. When we used to do resourcing, the business would estimate our resourcing for us:
There are seven people on the team doing a two week sprint, therefore, you have 490 man hours in this sprint, fit stories and tasks in that equate to those hours, you can have 15% of that figure for bugs.
-Somebody from the business
We quickly realised (well, as a team, we realised this was wrong immediately, but the business will always wait for empirical evidence first) that this wasn’t going to work. There is no way each team member can dedicate seven hours a day to the sprint. There are numerous things that vie for your time; getting a coffee, taking a piss, talking to colleagues, talking to the business, researching your industry, emailing your wife, checking your bank balance, rebooting your Windoze computer on a AD network which takes about 15 minutes, getting a coffee, etc, etc.
So, sprint after sprint failed (let me be clear, the sprints didn’t “fail” as the business always decided we “drop” something low priority from a sprint before the end but, as a team, that feels like a failure) and this could be down to bad estimating of ideal hours for tasks, true, but this is compounded by bad resourcing.
If you resource incorrectly, your entire sprint is undermined as it’s the basis for deciding what you commit to, you have an inflated idea of how many ideal hours you can deliver and so you over commit. Your gut feeling is always “this is too much work, we’re overcommitting!” but the math is right? So, it should fit in, right? RIGHT?
No, wrong. It won’t. Neither will pretending it will fit in and then dropping stories at a later stage work either. This will undermine the teams ability to deliver quality working software as there is always this grey cloud of unachievable stories hanging on like a bad smell at the end of your sprint backlog. The team will inevitably rush through what they’re doing to try and deliver what they’ve (been forced to) commit to. This is bad on many quite obvious levels, so I won’t spell them all out…
… OK, I will. This will result in less than polished code, rushed, hurried unit tests. Bothered and harrassed QA roles (if you have them) a stressed release manager as he’ll be backward and forward with UAT, an annoyed stakeholder as the stories get rushed, other annoyed stakeholders as their stories get dropped and, finally, a shoddy release of badly written, implemented, tested and released code.
Exaggeration? Maybe. But it makes my point.
If you ask each team member “How many hours a day can you commit to, ideally?” when you’re resourcing. You’ll get a worst case scenario on the amount of ideal hours you have. If you then estimate and plan based on that, you’ll ALWAYS deliver what you commit to (unless you get the planning REALLY wrong) and, usually, have time at the end to pick up an extra story, fix an extra bug, research a new technology or whatever. Everyone wins; the team are happy that they’ve delivered what they’ve said they would (and, maybe more) and the business is happy as they’ve managed external expectations and delivered the commitments and perhaps even more happy if another story was squeezed in, or an extra bug or two squashed.
I understand that you need to know where inefficiencies are, I really do, I want to know also. If the team are kicking around spending three hours a day reading XKCD and reading LOLCats, then I want to know as well and why. But they aren’t they’re spending the time doing actual work. So, let them do it and don’t force them into it.
If you want to measure time spent on things other than the sprint, then use something other than the sprint to measure that time. Resourcing and estimating/planning won’t help you here as they are, after all, just estimates.
