Produce with Flow | Blog Home | Fractal Planner

Agile SCRUM for One (part 2): Big Projects and Sunk Costs

If you’re a creative individual, working for yourself, or mostly by yourself, big projects can mess with your mind.

One reason for this is because of the “sunk costs” that accrue as you go.

In this post I’m going to explain what sunk costs are, why they make big projects a pain, and how a process borrowed from group software development can help you avoid the agony they can bring, whether you’re writing a book, launching a multi-media information product, painting a masterpiece, or writing a symphony.

The solution I will advocate comes from a practice called SCRUM. We’ll get into more detail about the “SCRUM” process — or part of it anyway — in a couple posts.

Scrum, in its full glory, is made for teams, but I see no reason individuals cannot benefit from planning big projects as a series of shorter sprints, each of which ends in an opportunity for feedback. In fact I know from personal experience that this pays big dividends.

Sunk Costs

So, sunk costs. What are they? And how do they apply to our big projects?

Let’s say you’re writing a book, and it’s going to take 6 months to write. At the 3 month mark, you’ve done a lot of writing, and you cannot undo it. You can abandon your project, but you can’t get that time and effort back. It’s gone.

Those three months are a “sunk cost”.

Sunk Costs and Doubts

Sunk costs become a problem when we start having doubts about our projects.

Let’s say at the three month mark you start having doubts about your book. You’re now unsure anybody will like it.

When you started with the outline of your book, you could imagine everyone loving it. It would be published and become an underground success. Hollywood would come calling, and you’d get royalties from movie ticket sales for the movie that would be made.

But now you’re not so sure. Your plot has taken turns you didn’t anticipate, and some of your characters are starting to annoy you.

Let’s also say that you’re mulling over 3 other projects that seem like they might be better to work on than the one you’re in the middle of.

What do you do? This can be agonizing. Some people leave their manuscript aside and begin working on other projects, intending to get back to this one when inspiration strikes again. Others plow through.

The Dilemma

What SHOULD you do?

That’s not an easy question to answer.

What if your project really is a dud, and you sink another 3 months into it?

But what if it’s actually quite good, and you don’t work on it?

Also, if you abandon the project, how do you justify the way you spent the last 3 months — to yourself, and others who might be depending on you to finish a successful project?

On the other hand, decision theorists will warn you not to fall for the “sunk cost fallacy”. The idea here is that, at any point in time, you should choose the path that has the most promise, regardless of how much time, money and effort you’ve already sunk into the current project.

If you’re 3 months into a book, and Steven Spielberg comes calling for you to write a screenplay for a movie he wants to produce, and he gives you a $100,000 advance, you switch horses. No-brainer, right?

But our choices aren’t usually that stark. We often have to choose between that current project we’re doing, and another that feels more promising, but has just as many unknowns attached to it as the one we’re working on.

And, while the sunk cost fallacy can be a problem, there is another problem that can arise for those who virtuously avoid it. Let’s say you take on a 6 month project, and at the 3 month mark a better opportunity comes up that will also take 6 months. So you switch horses. Then, in the middle of that project yet another even better opportunity comes up. And so on ad infinitum.

In this case, by always making the “rational” choice, you wind up never getting anything completed. You might well have been better off just finishing the first project and living with its meager payoff rather than eternally deferring ever bigger payoffs.

So, opposed to the “sunk cost fallacy” we have the “chasing rainbows problem”.

Dilemmas like this can be discouraging, and sometimes even debilitating.

Looking Forward to Solving the Dilemma

Fortunately, I think sunk cost dilemmas are largely avoidable. (Note: the “sunk cost dilemma” discussed here is different than the one traditionally discussed by economists. But it’s just a real!) Or, at the least, we can make them less dramatic.

The key is to plan our big projects in such a way that we get more feedback on them along the way.

But it has to be the right kind of feedback.

Stay tuned for more.

Comments welcome (as always!)

Share
This entry was posted in agile sprints, frequent feedback, SCRUM for One, sunk costs and tagged , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

7 Comments

  1. Elona
    Posted June 16, 2011 at 8:56 am | Permalink

    Just came across this blog and your software . . . you are describing my entire life!!! I am a writer and a small business wanna-be. I am still a wanna-be after countless years because of exactly these issues. THANK YOU! Somehow, just hearing someone describe what’s been going on in my (very logical, yet easily distracted) mind has helped me to see the forest for the trees. I have felt so frustrated and derailed for the past several years. Any help you can offer will be read and saved and applied. I look forward to your next post. Thanks again!

    • Jim Stone
      Posted June 16, 2011 at 10:26 am | Permalink

      Hi Elona. I’m glad to hear this. You’ve made my day!

  2. Sarah
    Posted June 20, 2011 at 10:13 am | Permalink

    Indeed, connection is going to be a key in all of this, and the entrepreneurial life is a rather solitary one. Figuring out how to get feedback (like, as a writer, posting excerpts to a blog and/or joining a writers group) can be really helpful.

  3. Posted June 21, 2011 at 10:32 am | Permalink

    Nice explaination of sunk costs, doubt, and the resulting dilemma faced by most of us.

    There’s one other aspect that conspires to confuse and confound creative individuals and that is the emotional contribution.

    I referring to the belief/obsession that often gets us started on a project because we think we have a great solution. The problem is that few people have the problem needing our great solution. But we persist, putting months and months of work into our pet project only to find, after unveiling to the world, that no one is interested.

    If only we knew sooner. (But would we listen?)

    Looking forward to your solutions.

    • Jim Stone
      Posted June 23, 2011 at 1:45 pm | Permalink

      Lyle, it seems that if we get feedback sooner, we have a better chance of either abandoning the project, or changing it some so that it does scratch an itch in our intended audience. If we persist in the face of negative feedback, at least we won’t be proceeding under the delusion that everyone will love what we’re creating, and, if we persist, it will be for other reasons.

  4. Ron
    Posted November 17, 2013 at 8:27 pm | Permalink

    Very nice article, Jim. I could relate to this article as I read the Scrum Body of Knowledge (SBOK) from Scrumstudy, where they describe how Value based prioritization minimizes waste and sunk costs:

    The Scrum framework is driven by the goal of delivering maximum business value in a minimum time span. One of the most effective tools for delivering the greatest value in the shortest amount of time is value-based prioritization.
    Prioritization can be defined as determination of the order and separation of what must be done now, from what needs to be done later. The concept of prioritization is not new to project management. The traditional Waterfall model of project management proposes using multiple task prioritization tools. From the Project Manager’s point of view, prioritization is integral because certain tasks must be accomplished first to expedite the development process and achieve the project goals. Some of the traditional techniques of task prioritization include setting deadlines for delegated tasks and using prioritization matrices.
    Scrum, however, uses Value-based Prioritization as one of the core principles that drives the structure and functionality of the entire Scrum framework—it helps projects benefit through adaptability and iterative development of the product or service. More significantly, Scrum aims at delivering a valuable product or service to the customer on an early and continuous basis.

    Prioritization is done by the Product Owner when he or she prioritizes User Stories in the Prioritized Product Backlog. The Prioritized Product Backlog contains a list of all the requirements needed to bring the project to fruition.

    Once the Product Owner has received the business requirements from the customer and written these down in the form of workable User Stories, he or she works with the customer and sponsor to understand which business requirements provide maximum business value. The Product Owner must understand what the customer wants and values in order to arrange the Prioritized Product Backlog Items (User Stories) by relative importance. Sometimes, a customer may mandate all User Stories to be of high priority. While this might be true, even a list of high-priority User Stories needs to be prioritized within the list itself. Prioritizing a backlog involves determining the criticality of each User Story. High-value requirements are identified and moved to the top of the Prioritized Product Backlog. The processes in which the principle of Value-based Prioritization is put into practice are Create Prioritized Product Backlog and Groom Prioritized Product Backlog.
    Simultaneously, the Product Owner must work with the Scrum Team to understand the project risks and uncertainty as they may have negative consequences associated with them. This should be taken into account while prioritizing User Stories on a value-based approach (refer to the Risk chapter for more information). The Scrum Team also alerts the Product Owner of any dependencies that arise out of implementation. These dependencies must be taken into account during prioritization. Prioritization may be based on a subjective estimate of the projected business value or profitability, or it can be based on results and analysis of the market using tools including, but not limited to, customer interviews, surveys, and financial models and analytical techniques.
    The Product Owner has to translate the inputs and needs of the project stakeholders to create the Prioritized Product Backlog.

    Thus prioritization results in deliverables that satisfies the requirements of the customer with the objective of delivering the maximum business value in the least amount of time.

    • Jim Stone
      Posted November 26, 2013 at 10:52 am | Permalink

      Thanks for the comment, Ron. You provide a nice summary of SCRUM from a prioritization perspective. SBOK sounds interesting. I’ll check it out. I haven’t explored prioritization procedures much — though I understand how important they are. I will dive into that subject in depth at some point!

2 Trackbacks

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>