Answers to Shim’s Questions

Shim Marom has written quite nice recap on the ongoing #NoEstimates discussion. I decided to answer Shim’s questions. This is sort of sequel to the post I wrote last week.

1. Are cost estimates required in order to manage software projects?

It’s highly recommended to know the amount of $$$ you’re willing to spend. However, this doesn’t necessarily require formal cost estimating. Generally speaking, I would not do cost estimates, rather define the amount money I would be willing to spend, and then estimate capabilities based on that spending max. I can think of many cases, where that kind of “capability estimate” can be a really rough one.

2. Are cost estimates an effective tool for controlling costs?

This one I wouldn’t know. Usually I’ve been involved in situations where costs don’t need that much controlling, since they’re already known. In SW projects costs ~= labor costs, and if you fix a team and time frame, you pretty much don’t need cost estimate, because that is already known. In general I would be inclined to focus more on delivering and discovering value rather than controlling costs.

3. Do estimates stifle creativity and kill innovation?

Too detailed up-front bottom-up estimates can surely kill innovation. If you’ve already decided how (tasks) you’re going to deliver a feature, there isn’t that much room for coming up with alternative solutions. It’s even worse, if those features are “sub-tasked” by someone who doesn’t actually do the work.

It’s also about how innovative and creative you want to be. Sometimes you just need to install the frigging SharePoint sites, end of story. But you can surely be innovative and creative about how are you actually going to do that job. Best case scenario is that you find out that the customer doesn’t need SharePoint sites at all.

Innovation and creativity (regarding the product you’re building) must happen within the boundaries that business sets. How tight those boundaries are, is highly dependent on the business case. In research setups there are little or no boundaries. In “let’s go to moon” there are ton of boundaries.

4. Do people need estimates? And if so, why?

This is a tough one to answer in general level. In everyday life people need estimates all the time: how many milk cartons do I need, do I have enough time to cross the street etc.

I would say that in SW domain people need estimates, too. It’s the amount of certainty that is variable. For example let’s imagine an in-house R&D project. “Biz” may just decide to setup a team and spend $500k on it and see what pops out. But even in those cases there always is some kind of implicit estimate about the outcome of the project.

5. Is the very act of estimation results in the creation of uncertainty?

I don’t know how to parse this into English, so I’m not quite sure if I understand.

But yes, estimates — implicit or explicit —  are needed when the input data is incomplete, uncertain or unstable. Which is pretty much all the time.

6. Is estimation a practice still hanging over from the Waterfall era?

Not so sure about that. I would still claim that in waterfall project you need more upfront estimates than in more iterative setting.

7. Is No Estimation better than Bad Estimation?

Depends. I can easily come up with examples supporting both sides. For example in a “bad estimation” scenario team could just come up with a way too small an estimate for a task. Then that single figure could just be seen as it should be — outlier in team’s statistics. OR they could be held responsible for that estimate and questioned about the team’s performance. Really depends more on how you’re using that bad estimate.

If someone would force a general answer out of me, I’d say that no estimation is better than bad estimation. At least then you don’t have false sense of security, and you’re forced to think about cost/capabilities from some other POV than estimates.

8. Is Estimation really just a form of Guessing?

No. I see guessing more as decision making based on gut feeling or pure chance. Here is a good post about this question with which I more or like agree.

9. Are estimates necessary for Governance? Is it reasonable to require estimates for the purpose of pacifying governance needs?

Short answer: I don’t know.

Longer: I’m currently working in a publicly listed company, but I’m not quite sure if I understand what Governance means for me. Or what does pacifying governance needs mean. In reality it’s never “governance” that needs estimates, it’s more about meeting peoples’ needs. If there were a governance need, that doesn’t seem to make sense, I’d seriously consider what value does that governance need bring us.

10. Is there any point in providing estimates when it is known that many projects fail due to lack of credible estimates? And aren’t estimates a tool used to apportion blame afterwards anyway?

It’s an interesting claim that many projects fail due to lack of credible estimates. I’d like to see a bit more data about that one. My personal hunch is that the root cause for many projects’ failures is that they’re just too big. There are too many unknowns and high variability, so that coming up with an estimate with reasonable confidence interval is close to impossible. Add to this that estimates are often mistreated as commitments, and we have a nice little soup.

A couple of points still:

  • It’s not hammer’s fault if you use it to beat someone to death. (Maybe a tad vulgar analogy, sorry.) Both sides need to man up. For devs: if someone asks for an estimate, please ask first how is that estimate going to be used and what happens if you get it wrong. And for “biz”: don’t forget that estimates always have a probabilistic nature. Don’t use them to blame anyone.
  • You can get only so far by getting better at estimating. My go-to solution would be to find ways to split work into smaller programs and projects, which then enables us to have more credible estimates.

11. Is costing a necessary tool for determining business value?

Let me first start with everyday life examples, where “business value” is perhaps not considered.

Before knowing the price, I can know the value of, say,  a cup of coffee for me. It’s the “experience value” I’m expecting to get from drinking it . Same goes for going to movies. I can expect to get some kind of value out of it, I don’t need to know the price to know that.

Same goes for a little more complex examples, for example a new feature to my mobile phone. For example someone could offer me “I would create you an application that orders you a taxi with a single button click.” That feature has got a certain value for me, I don’t need to know the price of that feature for me. Nor do I need to know how much does it cost for the supplier to implement that feature.

However, I do need to know the price when I’m making decisions. A cup of coffee is “good value” for me, if it costs 1€ and I’m really craving for caffeine. If the price were 10€, my craving would need to be really bad for me to buy that coffee. In SW world it’s not enough to think about just the price, you need to think about the whole cost of the project, too. And what are the opportunity costs (what does it cost you because you decide to do project A instead of project B?).

In any case, I see the “value” and the “cost” as separate concepts, which are often used together to make business decisions. But they still are separate, at least in my head.

12. Does the scope drive the budget or does the budget drive the cost?

Well you can do either way. I’d prefer… wait a minute. I’d say this is a odd question. I would say budget drives the scope.

13. If estimates are required in order to support decisions, can decisions be made without estimates?

When human beings make decisions, estimates — implicit or explicit — are always made. I don’t know how to get around that fact.

How much will it cost and when will I get it?

Whether we like it or not, eventually someone will ask the dreaded questions: how much? when? Or the variant: what can I get with this money? This post is my view on the topic; how would I start answering those questions.

Disclaimers:

  • I don’t claim that this post covers all the things needed to manage a SW project. It’s probably just a scratch on that topic.
  • There are principles that are common to SW industry, but on the other hand there are so many different setups and domains that one perfectly good approach could be just the wrong one in different domain. So I’ll just say it once so that I don’t need to repeat it constantly: it all depends.  Use your own head.
  • I stole the title for this post from this great post by Neil Killick. Read that, too. And his other posts.

Our example case

A customer approaches you. He wants to build an application. It doesn’t matter what the application does, but let’s assume a non-trivial application like health care system for a municipality or order management system for a retailer.

Before you even begin

Before I would even begin to think about duration and price I would try to figure out the following:

  • Does this project have to be this big? Could we divide it into smaller projects, pick a most important one, and start with that?
  • How much money is the customer willing to spend?
  • Have we worked with this customer before?
  • Have we worked on this kind of software before? Has anyone worked on this kind of software before?
  • Is the team that is supposed to work on the project worked together before?
  • What is the risk involved? What happens if this project fails? What is the profit that we’re expecting to get from this project?

There are of course many possible outcomes when you answer these questions, but here I’m roughly classifying projects into these three categories:

  1. Big project, new customer, new kind of software for you and failure isn’t an option. Example: pension payment system that has a specific launch date. Banking software.
  2. New kind of software, expected gains are big, but you expect to fail often. Non-SW example: new drug development. Mobile game development. Composing a world class hit.
  3. Something between the extremes. You may have done similar project before or are familiar with the problem domain. If you fail, someone loses medium to large amount of money. Example: online ticket reservation system.

Which of these categories does your project fall into? Is it more like…

  1. In this case I’d strongly suggest to have a smaller “test project” to have some kind of the feasibility of the project. Otherwise I would be reluctant to even start. Or you might just want to politely reject that customer’s request. Not your piece of cake.
  2. In this case I would not spend too much time trying create a detailed work plan. Just set a budget and/or schedule and start doing. You don’t even know exactly what you are trying to achieve, so why would you try to break that work into smaller pieces? In this case you need a experienced team.
  3. Rest of the post assumes that your project falls into this category.

Create a solution blueprint / concept

So someone needs to know “how much?” I would address that need by gathering roughly the following information:

  • Goal / “mission statement” for the product
  • Business case for the product. Someone is always interested in $$.
  • High level capabilities/functionalities for the product. What does it do? This breaks down the general topic of your product into smaller pieces of functionality.
  • Main user roles
  • Main concepts of the product and their relationships as a concept map
  • Interfaces to external systems
  • Initial idea of the system architecture

Usually you do this with your own money. If you can do this with your customer’s money as a first phase of your project, good.

If needed and requested, I would use this information to create a top-down estimate about the project’s expenses. I would use any information I have available, for example data from similar past projects and expert opinions. It’s been a while since I last participated in top-down estimating, but there are plenty of resources out there, like this list and this gentleman.

Based on the estimate I would come up with some kind of minimum promise for the customer: this is what you get, minimum. If we fail to deliver, we deliver the rest on our own expense. I would probably come up with “this is what we are likely to deliver” and “this is what we deliver if things go really well” lists, too, if applicable.

During the project

In general, I would start with the most important capability and seek to deliver working software from day 1. If not day 1, then as soon as possible.

As you take the capabilities into development, break them down into smaller pieces. We call them epics, you might call them features, or something else. You might want to consider classifying these epics into S, M and L size lots. Do this as late as possible.

Epics still aren’t the raw food of the development team(s). Let the team split the work into user stories in co-operation with PO. Prefer “can we make this story smaller?” -heuristic over story point or other estimation techniques. If your team wants to split the story into tasks, fine, but don’t ever estimate those tasks separately. In any case, if your stories are small enough, you probably don’t need sub-tasks. Do the story splitting as late as possible, too.

Let the team decide a process / workflow on how they are going to deliver software that meets the constraints that your organization and your customer’s needs impose. Visualize that workflow, for example with kanban board. Gather metrics about the cycle times and queues in your system. Do you know how long does it take, in average, that your story has to wait until it gets to testing phase?

If it’s a new team that has never worked together, start with a school book process framework. Scrum is a good option. Make continual improvements to your process, see what works for your team. Henri Karhatsu has written about his team’s progress. It’s a nice read.

Measure epic throughput and use this data to fine-tune the original top-down estimate you did in the beginning. You might consider using story throughput instead, depending on the size of your project. Use this constantly updated information to answer the questions how much? when?

Conclusions / my view on #NoEstimates

I claim that during development, you don’t need to explicitly estimate development efforts. You don’t need to estimate stories using story points and estimate how many hours does it take to complete a task. I don’t see a need for bottom up estimates.

You can, and maybe even should, however, use the actual development velocity metrics to forecast the future. You know how many stories does your epics contain in average, and you know how much is your story throughput. Use this data to predict the future. Some call this estimating, and I’m fine with it.

Some say “you cannot predict the future”. Sure we can, we do it all the time as human beings. We cannot be 100% sure, ever, but we can make the percentage higher.

One final note on #NoEstimates. One light bulb moment for me was that #NoEstimates doesn’t mean #NeverEstimate. I would be comfortable if someone called the above described approach as #NoEstimates approach even though it possibly contains macro level estimating.

Lifehack: how to improve your memory

Sorry, I don’t know how to improve your memory.  But I do have one tip:

The best way to improve your memory is to organize your life so that you don’t need to use your memory that often.

I know the world is full of different reminder apps and todo lists and such.  For me, the problem with those is that I always forget to use them.  They don’t become natural part of my life.  My “trick” (which probably is common knowledge) is to inject reminders to my everyday life and tools that I already use.  A couple of examples:

  • It’s evening.  Suddenly it occurs to you that tomorrow you need to take the tax card to work.  Solution: place the tax card in front of the front door so that you cannot leave from home without noticing it.
  • Email is natural part of my life.  I often send email to myself.  For example  when work related idea comes to mind during weekend, I send the idea to my work email and then it’s off my mind.
  • Weekend is coming and you are in the middle of some programming task.  How to remember where to continue on Monday?  Leave a non-compiling line in the code so that compiler will remind you where you were.

You get the point!  I’d appreciate to hear if you, my dear reader, have got tips like these.

6 tips for handling technical stories

The value of vertical user stories seems to be quite familiar for the industry — create small slices of functionality from the users’ point of view, instead of writing horizontal “stories”, that cover only one component of your software.

However, there are times when these vertical slices just don’t seem to be enough. For example spiking new technologies, setting up development environment, enhancing the test framework, improving security, doing major refactoring work… you name it. Here are my tips how you may want to handle these kind of things in your project.

  1. Don’t try to force everything into a vertical story. Based on my experience, having everything as vertical stories is an idealistic state, which in practice isn’t possible to achieve. It’s like defects — you don’t want them, you fix them, but in practice you know that totally defect-free software isn’t possible.
  2. Prefer vertical stories. Having said #1, there is huge value in vertical functional stories, and by default you should always use them. It’s hard at times. If you fail, try harder. Non-user tasks should be used as a last resort.
  3. Have separate metrics for vertical stories and tasks. Whichever tool you’re using, have different issue types for vertical stories and non-vertical tech tasks and measure them separately.
  4. Consider time spent on technical tasks as cost of doing business. If your team isn’t familiar with needed technologies, it probably needs to spike them. Or if there are flaws in the test framework, you may need to spend time improving it. In a way the time spent on technical tasks is a property of the system, and in the course of time it should go down.
  5. Make it visible. For me, the issue with having everything done as a by-product of a vertical story is that it isn’t visible. If you encounter a major refactoring need when implementing a vertical story, one possibility is to do the refactoring  within the story, but then it’s not visible by any means. I’d prefer doing the work in separate task to make it more visible for the team.
  6. Express technical tasks in story format (if you want). You can express technical tasks in story format, if it fits your world and vocabulary. As a tester I need xxx to be configurable so that I can implement test yyy. Remember that these are not user stories, you’re just using story format. And by that I mean that those tasks don’t deliver value to the end user, they are just enablers for the “real” stories.

I do agree with Ron Jeffries that the code should be gradually improved by each vertical story, but in addition to that, there is a need for technical tasks. And there is nothing wrong in using story format in describing those tasks.

About freedom of choice

In Finnish(*) there is a phrase which actually carries plenty of wisdom:

Nothing is mandatory except death and taxes.

Let’s first imagine something you’d rather not do, but someone is insisting you to participate. Take Christmas shopping for example. Your significant other would like you to join her in hours of wandering in crowded department stores, but you’d rather stay home in your pajamas and play Xbox.

Basically you have four different approaches:

  1. You go shopping, but you feel resentful and irritated. “Here I am, in this hullabaloo, even though I don’t want to, I don’t deserve this.. let’s go home already…” 
  2. You stay home playing Xbox, but you feel guilty and perhaps ashamed of yourself. “Here I am, kind of enjoying, but hey, I should be shopping… now I don’t have present for my godson… and my partner is probably angry at me..”
  3. You choose to go shopping, but not out of guilt, but perhaps because you want to spend time with your partner, and to attend to her needs of companionship and doing things together. Maybe you go shopping because you choose that your desire to buy a present to your godson is greater than your desire to relax on the sofa.
  4. You choose to stay home playing Xbox, but just because you chose to be honest to your need to relax. And at this time it was greater than your need to attend to your partner’s needs. Not because you have somehow deserved it or because your partner “doesn’t have the right to insist me to go shopping”.

At this point you probably know where I’m going with this. Whatever you do, choose either approach number 3 or 4. It may seem like a small thing, but the difference in attitude does have a big impact on your mood. And at the same time you’ll be more honest to yourself and the people around you.

The liberty to choose goes to all aspects of life. You don’t need to work for that stupid boss. You may choose to do so, but perhaps because you need the money. You don’t need to give your child a car ride to hobbies every night, but perhaps you choose to do so because you don’t want her to walk alone in the dark. Etc etc.

I know this is easier said than done, but it’s worth a try to change the attitude.

(*) And originally Benjamin Franklin said: “[...] but in this world nothing can be said to be certain, except death and taxes”

What is scope (baby don’t hurt me)

The other night in a pub, Neil and I (and @karhatsu ) had an interesting chat about what does “scope” mean. We kind of disagreed then and I think we still do:

Maybe it’s just semantics or because I’m not a native English speaker, but I don’t agree. Let’s dive into this a little bit by first exploring the most common use case of that term: “X is out of scope“. So what does it mean when you say that something is out of scope? To me, X in this sentence is:

  • A feature (“supporting single sign-on is out of scope for now”)
  • A hardware change (“hardware changes are out of scope for you guys, they’re handled by the HW team”)
  • A certain testing type (“I’m not doing performance testing yet, it’s out of scope for this story”)

Then again, when I hear “amount of work”, I’m immediately thinking hours or days as the unit. Amount of work could be 16 hours or 2 weeks for example. But, in my opinion it’s wrong to say that scope = amount of work. There is a correlation between the scope and the amount of work needed to deliver that scope, but they’re not the same thing.

scope

 

This image above tries to illustrate this difference. We have a “fixed scope” in our naive book store example but different amount of work needed between the two teams. You could also imagine that the amount of work needed to deliver that scope is variable to a single team as well.  Team A could reduce the amount of work needed by making the process better etc. You know, the usual inspect and adapt, but that’s not the point of this post.

So what, one could argue. Well, maybe it’s just semantics, but on the other hand it’s easier to communicate if the community shares same terms and concepts. At least I’m still going to be on my toes when discussing “scope” with Neil. =)