TBT – Repost: Why Scrum Makes Planning and Estimating Worse, Not Better

Constraint based planning does not and cannot work in an industry without constraints. So, how do we plan without constraints? You can’t.

Planning is based on what you know prior to embarking on the journey. If I told you to pack a bag tonight because tomorrow we’re going on a trip, what would you pack? Oh, you want to know where we’re going, how long we’ll be gone, and what we’ll be doing? In other-words, you want me to provide the constraints of the trip so that you can plan accordingly?

I don’t know how to plan without constraints; and from what I’ve found so far no one does.

Instead what we’ll have to do is invent constraints. That means explore, poke, prod and plan, plan, plan before coding. Yes, do the exact opposite of what the oh-so-hip scrum methodology advises and [Mistake #1] plan before coding.

Second, [Mistake #2] ditch user stories and epics — at least at first. Use the planning period to define purpose, find solutions and then assign function.

Plan, Don’t Act
Scrum typically plans by piling stakeholders into a room at the start of a project to create a wall of index cards that describe function (wrong, see #2). From there, the product owner/manager works with the client to prioritize the backlog so that the team can create sprints from it every interval. The planning period? Often one exhausting day.

While I like the format and my point is not what the duration of a planning period should be — I believe their efforts are misguided. My first point is their concentration on function, not purpose — but I’ll save that riff for below.

Next, is the lack of discovery involved in scrum planning. The intent is to jump into a prototype and coding as soon as possible because there’s no other way to know whether what you’re doing is what the client wants.

That, I believe, has a lot to do with the fact that wireframes, benchmarking, user studies and other essential planning steps were left out during that epic day of sharpies, post-its and index cards. There’s no way to know if you’re on-track by writing a sentence on a 4×6 index card.

You need a way to do ‘x’? Why? Let’s back up and ask, what’s the sole purpose of this app? Is the function you just wrote down and stuck to the whiteboard going to help the app achieve that purpose? I didn’t think so. Then again, we could have just dumped that card into the next sprint, mocked it up, coded it and sent it to the client to make that realization.

You want feature creep? Then skip the discovery process and fill a whiteboard with posit-its that are supposed to come together as a well functioning app.

Solutions, Not Features

Scrum often works by placing large user stories (often called epics) in a list called a backlog. An epic, or user story describes a required function or feature of the site. For example, being able to login or manage users from an admin page. From here, estimates are prepared by assigning tasks to those user stories and summing them.


A user story describes function. The problem here is that the focus is on a function and not purpose.

What is the problem?

Until you know what the problem is, you can’t find a solution and without a solution you can’t define a function. Too many people place emphasis on function without asking why?

This leads to feature creep, unresolved issues and bloated estimates. By defining the purpose first — it allows solutions to be developed that result in function. The app’s feature set is auto-magically reduced by simply refocusing the planning efforts. You’re able to ask, “what value does that function provide?” because you know exactly what affect it has on the problem (because you know what the problem is).

Previously I wrote about how a button on a website that says “share” and is designed to share the content of the page with twitter, Facebook and the like can vary by a factor of ten depending on the implementation approach taken (that’s $100 versus $1,000). If you use a user story that says you need the function of being able to share a page you never get to ask why. And you’re never able to place a value on whether it should be done one way or another. Further, you’ll never know whether it needs to be there at all.

Finding the solution first reduces features, which saves money, time and technical debt. Function based planning leads to bloated apps.