Danger Will Robinson! Long post!
There is a chance this will be useful to you if some of the following are true:
So before we start:
If for some reason you're still with me, let me walk you through the method.
Let's say your team has been hired to bring Loretta and Steve Paizano's Pizza Palace into the 20th century, if not the 21st. Their grandson has convinced them that they need a web site. They are willing to go for it, hearing that their nephew Scotty down the street has increased his bakery revenue by $545 per month ever since he put up his web page, which allows customers to order pierogies for delivery. No, they don't have GrubHub there.
They want to know from you how much your team will charge to build the page for them. You are in Oshkosh, Wisconsin, your developer friend Monica is in Svalbard, Norway, and you have a tester friend, Anupam, in New Zealand. So you guys need to confer, but not in a way that involves Mom and Pop having to buy the three of you Second Life avatars and a high tech virtual team room with life-sized virtual planning poker cards. You all have internet phones, luckily, so talk is cheap. But what do you do for your estimation and release planning!?
Step 0: Know what you want to do, and type it into a shared spreadsheet. Why? Have you ever been on a conference call? Seriously--you need everyone to have a shared thing to look at. This is helpful for keeping people focused on the same thing, and it's crucial so that if there are problems with the quality of the phone lines (or if some people primarily process visual data rather than spoken information), people can read it as well as hear it. Choose a fast typist. This is where you are relying on readily available virtually FREE tools. You need:
If you can all look at the broadcasted screen together, and talk about it in real time on a shared audio line, you can do collaborative estimation and release planning.
Okay, so with everyone at their respective screen, and on a shared phone bridge, you start by asking your clients why they want a web site. The mom and pop team pass the phone back and forth between each other, and eventually they tell you about their problems, the goals, their dreams, and so on. As you talk, your fastest team typists records their motivations and potential solutions to their problems into the spreadsheet you are all looking at.
The Paizanos are in Newfoundland, and they drop off the call a lot, but they can see that at the end of the discussion, you've written stuff down they agree with:
The Paizanos are impressed that you can type so quickly. They agree this is what they want. Now you work together to break the features (which some of the Cool Kids call epics, but some don't) into individual "stories." As experienced agilists, the three of you suggest some stories in a flash. You keep track of which feature each story belongs to, so if the Paizanos need to make some hard decisions later, you can use filtering features in the spreadsheet to bring up the stories feature by feature.
Step 1: Now you're ready to focus on the stories. Use the "hide column" feature to help everyone focus, and just bring up the story list:
You have much to say to the Paizanos about the INVEST principals and the need for a standard story format, but I'll suppress those details for right now, because once you fix the stories to meet your own high standards, they won't fit nicely on the page here. They could be in extra columns on the spreadsheet which are hidden for the most part, though.
Step 2: Identify your "Minimum Viable Product," and don't worry right now about stories beyond your first release. Notice in this example that item six seem somewhat fanciful, and is all out of whack compared to the rest. Perhaps a mom-and-pop pizza store which will be lucky to have a read-only web site should not tackle computer-driven pizza-production automation for the first release. You get Mr. and Mrs. Paizano to agree that maybe you should get the site up first, and then deal with the automation piece in a later release. So now, here's what your list looks like.
Technically, perhaps, you could have had this discussion at the feature level, without even getting to stories, but the Paizanos needed to be humored for a while before you could have that discussion. Product Owners are sometimes like that. Last year, your team literally had to estimate the effort for building a working miniature version of the Saturn V rocket, before the Product Owner admitted that the desired scope exceeded the available budget. Even so, he kept shouting, "FAILURE IS NOT AN OPTION" a whole bunch of times. So you're feeling okay that all you had to do here was show goodwill by typing out a story, and then push the story to release 2.
Step 3: "Story Splitting." Make sure the stories left in Release 1 are a reasonable size for the team to estimate. Monica is only available to develop your software when she's on break from her job at the Global Seed Vault, so about ten hours a week. Handily, Anupam is willing to test "whenever," because all he does in New Zealand is surf. So Monica's time is your real constraint.
Your team decides to use a two week iteration for the work, which gives you 20 hours of Monica's time per iteration.
In order to give the Paizanos a really clear estimate, you all agree that no story should be tackled for estimation purposes which is larger than 10 hours, so that you know you'll be delivering at least two meaningful stories worth of work to the Paizanos per iteration. To ensure this is the case, you do "story splitting," where you take stories that are too big, and divide them into sub-stories that are small enough to estimate. You, Monica, and Anupam walk through the spreadsheet line by line and determine quickly whether anything seems bigger than 10 hours.
Monica observes that if all they want to do is let people see a "Buy Now" button she can implement through PayPal, that's no problem, but if the Momstress and Pop-Tart want for people to buy multiple pizzas in one order, she's going to have to implement a more complex shopping cart, which could take ten hours in itself. Following similar logic, you break down the "Refund handling" request as well. Now you have this new version of your list, post-Story-Split, where everything is the right size. You've left the old stories in for reference, but crossed them out to indicate they are now fully superseded:
Step 4: "Comparative Estimation" Although you are all quite giddily certain that the stories are now all in the right ballpark, size-wise, you want a higher level of precision for iteration planning. But Monica gets all freaked out if you ask her to provide time estimates. She will take a story like "login to the system" and estimate it at 120 hours, just in case she has to stop and try to get a manicure in the middle, and Svalbard is out of nail varnish, and she has to get it FedExed from the mainland.
So rather than get into another argument about that, instead, you all agree to put time completely out of your mind and just do comparative sizing. You start by hiding the stories you're not going to do in the first release, and you set all the stories you are going to do, to the default size of "Medium."
Now you march through the lines one at a time as a group on the phone looking at the spreadsheet together, and compare them. Story 2 seems smaller to Monica than Story 1, so if 1 is "Medium," then 2 is "Small." So is 3. 7 seems bigger. Anupam chimes in about the regression test load on 10. And so on. In the end, you have stories comparatively sized something like this:
If you're familiar with the Agile "Fruit Estimation Game," it's as though the three of you have simulated a rating system whereby Story 1 was an apple, Stories 2, 3, and 9 were plums, Story 7 was a grapefruit, and stories 8 and 10 were pineapples. But no expensive fruit was used--just a FREE spreadsheet! But what now? Neither your t-shirt sizes nor their fruit equivalent will convey useful information to the Paizanos about the cost and timeline of the project. So why did you go to all this trouble?
New agile teams are always eager to start estimating in "points." Points are what the Cool Kids use. Often, however, for teams that haven't done agile before, the points are just disguised time estimates. In Monica's case, for example, if you had started with points, she would have said the login page was 120 points, with 1 point = 1 hour. So you purposely don't do that. But now that you have safely estimated everything comparatively, you can enter the Cool Kid World of Story Points, and you do it really easily, circumventing Monica's crazy manicure fixation. You can translate directly from t-shirt sizes to numbers using this scheme from Fibbonaci: XS = 1, S = 2, M = 3, L = 5, XL = 8.
Applying this logic, your spreadsheet now looks like this:
But we still don't know what this means for time or cost (insofar as we will be paying ourselves for the time we spend in each iteration). So now what?
Step 5: Team Velocity Estimation. "Velocity" is a fancy agile term for "the number of story points your team will complete in a single iteration." The best way to calculate velocity is to have your team do a few iterations and see how much they get done. But the Paizanos, like many funding authorities, prefer to get the estimate first, and then commit the funds. So rather than determining velocity empirically, we use a set of simulations to put the team into a frame of mind where it predicts the amount of work it could get done in a single iteration. To avoid the newbie agile impulse to equate points to hours, we temporarily hide the points, and ask the team to pick groups of stories they could get done (developed, tested, and approved by the Paizanos) in two weeks. Here's what the spreadsheet would look like to start with:
You, Monica, and Anupam start by looking for a random set of work that could be done in 2 weeks, where Monica is only available when she's on break. You carefully avoid any mention of "how long will each one take." Instead, you focus on what combinations would add up to the right total amount of work, disregarding dependencies. You are going to deal with dependencies in just a moment. For now, you just chill, and get into the focused Zen state of picking combinations that add up to the right amount of work). After a while, you decide as a group on three combinations that seem as though they could fit into two weeks:
Because you're totally Zen and chill, you don't mind that story 8 involves refactoring code that you haven't actually written yet. For purposes of velocity estimation, you assume all dependencies are handled. So maybe combination H is going to be iteration 10, where combination I would occur in iteration 3. All you're doing here is figuring out the team velocity. You're not actually assigning any story to any iteration.
So, voila, you can now use your three sample "chunks of work" to estimate team velocity. Unhide the points column, and see whether there's a pattern in terms of how many points the team wants to tackle per iteration.
Column H represents 10 points worth of work, Column I represents 8 points worth of work, and Column J represents 10 points. So if the simulation is accurate, this team expects to be able to do about 9-10 points of work per iteration.
Step 6: Calculate minimum project duration and cost. Even before you try to figure out which story should go in which iteration, you now have a lot of useful information to give to the Paizanos. Since you know that:
Total points = 30
Estimated team velocity = 10 points/iteration
You know that all things being equal, it will take your team 3 iterations to complete the work, although if every story has to be done in a particular sequence, you may have an even longer time frame. So you can go to the Paizanos and tell them truthfully that they will need to pay your team for at least 3 iterations, but possibly 4. Do they want to move forward? Your team charges $400 per iteration.
Step 7: Adjust to fit desired budget. It turns out the Paizanos only want to spend $800, and see whether they actually start getting the extra $545 that Scotty saw. If things work out, they will come back for more work. They ask you to fit the work into 2 iterations, not 3. You tell them that now that the work has been broken down into these small pieces, you don't see any way to have the work take less than 3 iterations. Then you suggest that maybe the Paizanos could look through the stories and see if some of them could come out of the first release, even beyond what you agreed to before. You suggest that they prioritize the stories, so that everyone will know what the least important ones are, and it will be easy to cut 10 points worth of work off of the project schedule.
They prioritize and you resort. Now it looks like this:
It appears that the Paizanos have significant pizza quality problems, so automating refunds is actually more important to them than enticing customers to buy a whole virtual cartload of pizza! You're intrigued but a little sad. You want to give them your mom's tomato sauce recipe, but instead you point out that if they give up on the shopping cart for now, you will be able to deliver the other six features in a little more than 2 iterations. Maybe you could split the difference somehow. They seem happy with the offer. Now, if you unhide your "release" column and the row that you already designated for the second release, your list looks like this:
Reassured that you remember what they want for release 2, the Paizano's ask you to finish your estimation and actually let them know when they will have each feature available for their customers. So you move quickly to:
Step 8: Organize stories into actual iterations. For this project, you now have six stories to put into two iterations. You need to:
There is a chance this will be useful to you if some of the following are true:
- You're an agile software development practitioner who needs to provide an overall "fixed cost" type estimate for your work. This might be because the corporate entity paying your team insists on you providing such an estimate before it will commit a single penny to pay you, your team, or your "team room snacks" bill. Or you're billing time-and-materials, which is great, but someone still wants a ballpark of what the total will be for what it currently seems the project subject matter is kind of about.
- You would normally do your estimate by getting everyone into a room for a co-located "project inception" or "planning game" or "story mapping and release planning session" where you would do this estimating by moving physical cards around on a table, floor, or wall.
- You don't actually have the whole team physically together, so any activity with index cards has to be reported to the "remote" people through shouting and a single digital camera built into someone's laptop. Example:
"Preet! Preet! We took the third PURPLE Post-It and put it over to the FAR LEFT. So widget 3 is now part of the "Useful Widgets" epic we're doing in Release 4. I'll pan the camera over there for you to see it!"
I can tell you from experience that the people in India joining your call by phone aren't getting as much out of this as you think, particularly if it is 3am their time.
 |
| Webcam-eye view of your team room as seen from far away from a good post on this topic, although I disagree with the author's conclusions: http://www.gerrykirk.net/options-for-team-task-board-when-one-team-member-remote/ |
- If you're a person who thinks agile should never involve planning (see my rant about the need for life before iteration 1 here), this is not for you.
- If you're a person who thinks agile must always be done in person by the whole team, using 3M products, this is not for you (see my rant about distributed agile being a reality we should all face here). I absolutely agree it would be better if we could all collocate all the time, but we can't, so let's work with what we have.
- If you're a person who thinks distributed agile requires specialized high-tech tools to be done right, I'm with you! However, we don't all always have those tools available, so I'm providing this alternative suggestion with tools you can get for FREE. But if you do have the right tools, and they're legally licensed and so on, you can read this and feel happy if you like.
 |
| The enviable TechSmithies at Agile 2012: http://blogs.techsmith.com/wp-content/uploads/2012/08/agile2012_techsmithies.jpg |
Let's say your team has been hired to bring Loretta and Steve Paizano's Pizza Palace into the 20th century, if not the 21st. Their grandson has convinced them that they need a web site. They are willing to go for it, hearing that their nephew Scotty down the street has increased his bakery revenue by $545 per month ever since he put up his web page, which allows customers to order pierogies for delivery. No, they don't have GrubHub there.
They want to know from you how much your team will charge to build the page for them. You are in Oshkosh, Wisconsin, your developer friend Monica is in Svalbard, Norway, and you have a tester friend, Anupam, in New Zealand. So you guys need to confer, but not in a way that involves Mom and Pop having to buy the three of you Second Life avatars and a high tech virtual team room with life-sized virtual planning poker cards. You all have internet phones, luckily, so talk is cheap. But what do you do for your estimation and release planning!?
Step 0: Know what you want to do, and type it into a shared spreadsheet. Why? Have you ever been on a conference call? Seriously--you need everyone to have a shared thing to look at. This is helpful for keeping people focused on the same thing, and it's crucial so that if there are problems with the quality of the phone lines (or if some people primarily process visual data rather than spoken information), people can read it as well as hear it. Choose a fast typist. This is where you are relying on readily available virtually FREE tools. You need:
- Phone access (everyone has internet phones on your team, weirdly, even including the Paizanos).
- A chosen spreadsheet format (Google has a free one, and there are others out there. Often people have one they've paid for)
- A chosen way to share your voices and one screen, including free options like Skype and the like.
If you can all look at the broadcasted screen together, and talk about it in real time on a shared audio line, you can do collaborative estimation and release planning.
Okay, so with everyone at their respective screen, and on a shared phone bridge, you start by asking your clients why they want a web site. The mom and pop team pass the phone back and forth between each other, and eventually they tell you about their problems, the goals, their dreams, and so on. As you talk, your fastest team typists records their motivations and potential solutions to their problems into the spreadsheet you are all looking at.
The Paizanos are in Newfoundland, and they drop off the call a lot, but they can see that at the end of the discussion, you've written stuff down they agree with:
The Paizanos are impressed that you can type so quickly. They agree this is what they want. Now you work together to break the features (which some of the Cool Kids call epics, but some don't) into individual "stories." As experienced agilists, the three of you suggest some stories in a flash. You keep track of which feature each story belongs to, so if the Paizanos need to make some hard decisions later, you can use filtering features in the spreadsheet to bring up the stories feature by feature.
Step 2: Identify your "Minimum Viable Product," and don't worry right now about stories beyond your first release. Notice in this example that item six seem somewhat fanciful, and is all out of whack compared to the rest. Perhaps a mom-and-pop pizza store which will be lucky to have a read-only web site should not tackle computer-driven pizza-production automation for the first release. You get Mr. and Mrs. Paizano to agree that maybe you should get the site up first, and then deal with the automation piece in a later release. So now, here's what your list looks like.
Step 3: "Story Splitting." Make sure the stories left in Release 1 are a reasonable size for the team to estimate. Monica is only available to develop your software when she's on break from her job at the Global Seed Vault, so about ten hours a week. Handily, Anupam is willing to test "whenever," because all he does in New Zealand is surf. So Monica's time is your real constraint.
Your team decides to use a two week iteration for the work, which gives you 20 hours of Monica's time per iteration.
In order to give the Paizanos a really clear estimate, you all agree that no story should be tackled for estimation purposes which is larger than 10 hours, so that you know you'll be delivering at least two meaningful stories worth of work to the Paizanos per iteration. To ensure this is the case, you do "story splitting," where you take stories that are too big, and divide them into sub-stories that are small enough to estimate. You, Monica, and Anupam walk through the spreadsheet line by line and determine quickly whether anything seems bigger than 10 hours.
Monica observes that if all they want to do is let people see a "Buy Now" button she can implement through PayPal, that's no problem, but if the Momstress and Pop-Tart want for people to buy multiple pizzas in one order, she's going to have to implement a more complex shopping cart, which could take ten hours in itself. Following similar logic, you break down the "Refund handling" request as well. Now you have this new version of your list, post-Story-Split, where everything is the right size. You've left the old stories in for reference, but crossed them out to indicate they are now fully superseded:
Step 4: "Comparative Estimation" Although you are all quite giddily certain that the stories are now all in the right ballpark, size-wise, you want a higher level of precision for iteration planning. But Monica gets all freaked out if you ask her to provide time estimates. She will take a story like "login to the system" and estimate it at 120 hours, just in case she has to stop and try to get a manicure in the middle, and Svalbard is out of nail varnish, and she has to get it FedExed from the mainland.
So rather than get into another argument about that, instead, you all agree to put time completely out of your mind and just do comparative sizing. You start by hiding the stories you're not going to do in the first release, and you set all the stories you are going to do, to the default size of "Medium."
Now you march through the lines one at a time as a group on the phone looking at the spreadsheet together, and compare them. Story 2 seems smaller to Monica than Story 1, so if 1 is "Medium," then 2 is "Small." So is 3. 7 seems bigger. Anupam chimes in about the regression test load on 10. And so on. In the end, you have stories comparatively sized something like this:
If you're familiar with the Agile "Fruit Estimation Game," it's as though the three of you have simulated a rating system whereby Story 1 was an apple, Stories 2, 3, and 9 were plums, Story 7 was a grapefruit, and stories 8 and 10 were pineapples. But no expensive fruit was used--just a FREE spreadsheet! But what now? Neither your t-shirt sizes nor their fruit equivalent will convey useful information to the Paizanos about the cost and timeline of the project. So why did you go to all this trouble?
New agile teams are always eager to start estimating in "points." Points are what the Cool Kids use. Often, however, for teams that haven't done agile before, the points are just disguised time estimates. In Monica's case, for example, if you had started with points, she would have said the login page was 120 points, with 1 point = 1 hour. So you purposely don't do that. But now that you have safely estimated everything comparatively, you can enter the Cool Kid World of Story Points, and you do it really easily, circumventing Monica's crazy manicure fixation. You can translate directly from t-shirt sizes to numbers using this scheme from Fibbonaci: XS = 1, S = 2, M = 3, L = 5, XL = 8.
Applying this logic, your spreadsheet now looks like this:
But we still don't know what this means for time or cost (insofar as we will be paying ourselves for the time we spend in each iteration). So now what?
Step 5: Team Velocity Estimation. "Velocity" is a fancy agile term for "the number of story points your team will complete in a single iteration." The best way to calculate velocity is to have your team do a few iterations and see how much they get done. But the Paizanos, like many funding authorities, prefer to get the estimate first, and then commit the funds. So rather than determining velocity empirically, we use a set of simulations to put the team into a frame of mind where it predicts the amount of work it could get done in a single iteration. To avoid the newbie agile impulse to equate points to hours, we temporarily hide the points, and ask the team to pick groups of stories they could get done (developed, tested, and approved by the Paizanos) in two weeks. Here's what the spreadsheet would look like to start with:
You, Monica, and Anupam start by looking for a random set of work that could be done in 2 weeks, where Monica is only available when she's on break. You carefully avoid any mention of "how long will each one take." Instead, you focus on what combinations would add up to the right total amount of work, disregarding dependencies. You are going to deal with dependencies in just a moment. For now, you just chill, and get into the focused Zen state of picking combinations that add up to the right amount of work). After a while, you decide as a group on three combinations that seem as though they could fit into two weeks:
Because you're totally Zen and chill, you don't mind that story 8 involves refactoring code that you haven't actually written yet. For purposes of velocity estimation, you assume all dependencies are handled. So maybe combination H is going to be iteration 10, where combination I would occur in iteration 3. All you're doing here is figuring out the team velocity. You're not actually assigning any story to any iteration.
So, voila, you can now use your three sample "chunks of work" to estimate team velocity. Unhide the points column, and see whether there's a pattern in terms of how many points the team wants to tackle per iteration.
Column H represents 10 points worth of work, Column I represents 8 points worth of work, and Column J represents 10 points. So if the simulation is accurate, this team expects to be able to do about 9-10 points of work per iteration.
Step 6: Calculate minimum project duration and cost. Even before you try to figure out which story should go in which iteration, you now have a lot of useful information to give to the Paizanos. Since you know that:
Total points = 30
Estimated team velocity = 10 points/iteration
You know that all things being equal, it will take your team 3 iterations to complete the work, although if every story has to be done in a particular sequence, you may have an even longer time frame. So you can go to the Paizanos and tell them truthfully that they will need to pay your team for at least 3 iterations, but possibly 4. Do they want to move forward? Your team charges $400 per iteration.
Step 7: Adjust to fit desired budget. It turns out the Paizanos only want to spend $800, and see whether they actually start getting the extra $545 that Scotty saw. If things work out, they will come back for more work. They ask you to fit the work into 2 iterations, not 3. You tell them that now that the work has been broken down into these small pieces, you don't see any way to have the work take less than 3 iterations. Then you suggest that maybe the Paizanos could look through the stories and see if some of them could come out of the first release, even beyond what you agreed to before. You suggest that they prioritize the stories, so that everyone will know what the least important ones are, and it will be easy to cut 10 points worth of work off of the project schedule.
They prioritize and you resort. Now it looks like this:
Reassured that you remember what they want for release 2, the Paizano's ask you to finish your estimation and actually let them know when they will have each feature available for their customers. So you move quickly to:
Step 8: Organize stories into actual iterations. For this project, you now have six stories to put into two iterations. You need to:
- Deliver in priority order as much as possible, since the Paizanos ranked these by their expected return on investment for each feature
- Make sure the iterations have about the same number of points in them
- Make sure that you handle any dependencies between the stories. You can't "refactor" something that doesn't exist, for example.
- If anything is a more technically risky, Monica would like to schedule that first, because if she can't figure it out, she doesn't want the Paizanos to have to pay for a second iteration, since the whole thing will be a bust.
- Stories 1, 2, and 7 are scheduled for Iteration 1, and Stories 3, 9, and 10 are scheduled for Iteration 2.
- Total expected velocity for Iteration 1 = 10 (add the points for stories 1, 2, and 7). Expected velocity for Iteration 2 = 12. So the work appears to be set up to be around the expected team velocity of 9-10, although you seem to have let your pity for the Paizanos lure you into over-committing. Tut tut.
- For the most part, the things the Paizanos ranked as important are happening more in Iteartion 1 than in Iteration 2.
- Monica has been able to put two of her high risk items into Iteration 1.
- Logical dependencies are observed--the system is set up for login before any user actions are added, for example. And the refund page is created in Iteration 1, and only in Iteration 2 do you add features for automating the refund.
The Paizanos doubtfully write you an advance check for the first iteration, and you run out to buy snacks and then FedEx them to Svalbard and New Zealand. They don't have string cheese in New Zealand. You did it! You did it! You're ready for Iteration 0! Huzzah!
Comments
Post a Comment