Priority #1

Posted on Leave a commentPosted in management

How often do you ask your main stakeholders about first priority features?

Should we analyse feature A first or feature B first? Should we start working on A, B or C?

Do you think that prioritization would remain the same with following options (assuming that we know potential users and revenue)?

  • Option 1
    • A – 1 month; B – 1 month; C – 1 month.
    • Teams involved: A – 1 team; B – 1 team; C – 1 team.
  • Option 2
    • A – 1 month; B – 1 month; C – 1 month.
    • Teams involved: A – 3 teams; B – 4 teams; C – 2 teams.
  • Option 3
    • A – 3 months; B – 2 months; C – 4 months.
    • Teams involved: A – 3 teams; B – 5 teams; C – 2 teams.

What additional information apart intuition do you use in decision making? Do you use spikes to improve decision making?

Best answer when ask for estimates is NO

Posted on Leave a commentPosted in management

You’ve been a lot of times in a situation when you have a problem (or at least you think so), money to solve that and you ask someone for estimates to understand when you are going to get your solution.

As a product owner you want to hear that you will get that thing in one sprint, not three.
As person looking for outsourcing company you might want to spend less money.
This list can go longer, but basically you want hear a number.

In most cases people who request estimates don’t event expect to have another answer – discussion. They just need estimates to make their decision or pass over this information further so others could do that instead.

I instead expect to hear following answer a team – “No, you don’t need that! Because…” or “Hm, no. Let’s take a look at alternatives…” or “Why? Did you think of this?”

This “NO” means following to me:

  • team knows the domain
  • there is trust between me and team
  • there is a valuable discussion
  • we can achieve better results

Otherwise you have a bunch of doers or an army, but maybe it’s just what you prefer better.


High level estimate for any project

Posted on Leave a commentPosted in management, quick thoughts

Set up a dart board. Each point on the dart board represents $1M (1-20). The rings represent the following:

  • The bulls eye is $100k
  • The ring around the bullseye is $300k
  • The next ring out is .6x
  • The outer ring is .8x

Take three darts and aim for the bullseye. Average the scores of the three shots. This is your “high-level” estimate for each project.

p.s. originally read it somewhere and found it reviewing my notes 🙂

Uncertainty in estimates

Posted on Posted in management

Very good summary of what problems we face while making a schedule –

Why Uncertainty Exists
Suppose we are estimating the effort required to remodel a house. We will start by breaking down the project “Remodel House” into a few smaller steps, namely

Remodel Kitchen
Remodel Bedroom
Remodel Living Room
We want to estimate the effort required for each of these steps, such as “Remodel Bedroom.” Unfortunately, our estimate will not be exact. Estimates differ from reality because of uncertainties, which arise in many ways

Incomplete Understanding of Scope

We may not have accounted for all the requirements. Do we need to replace the baseboards? If we didn’t think about the baseboards, our concept of scope is missing an important element, and our estimate will not include the work to replace them.

Incomplete Understanding of Work per Scope

Perhaps we did include baseboard replacement in scope, but we assumed the effort involved was limited to nailing the new ones in position. Unfortunately, we didn’t account for the work required to measure and cut the baseboards to the right size, so even though the scope was right, the effort estimate will be too low.

Imperfect Understanding of Known Work

Even if we did remember all of the work that needs to be done for the baseboards, and estimate accordingly, our estimates may be off because some of the boards split when nailed. We will either have to replace those baseboards, or drill them to avoid splitting when we nail them. Either way, the work will increase beyond our estimate.

Inability to Forecast the Unexpected

What happens if the paint we need is out of stock, or someone delivers the wrong baseboards? These external events are unpredictable, and disrupt our schedule.

How to Cope with Uncertainty
Once we have reduced uncertainty to a practical minimum, the only other thing we can do is to take the remaining uncertainty into account in our process. We’ll look at strategies suited for projects that are subject to different kinds of constraints below. (For simplicity, we’ll assume that resources are fixed, since the ability to add resources does not vary in a meaningful way between the different scenarios. Similarly, we also assume that scope is well-enough controlled to prevent scope creep.)

Fixed Schedule, Fixed Scope

The first thing to understand about this set of constraints is that success is not always possible. If scope is truly fixed, and schedule is subject to uncertainty, then we have already seen that extreme cases will break any schedule.

These projects are planned with uncertainty in mind, by adding enough buffer time into the schedule to handle a reasonable level of uncertainty (for example, allocate 30% of the schedule for this purpose). This approach works well in situations where uncertainty is small, such as for repeating processes (e.g., laying carpet, or painting houses).

Fixed Schedule, Adjustable Scope

Many agile project-management frameworks handle uncertainty by committing to the only thing that can truly be controlled, which is the schedule, and adjusting the scope as required to meet the schedule. This strategy is particularly useful in high-uncertainty environments, where estimation is known to be inaccurate, and where scope is not well-understood and may change frequently.

The Scrum framework handles this situation effectively. It requires careful planning, but in a way that handles high uncertainty gracefully. Scrum projects work in short cycles to deliver modest increments of scope quickly, and to allow for frequent changes in scope and priority. Within each cycle, scope is adjusted as necessary in order to guarantee that the schedule is met.

No Schedule, Unknown Scope

Uncertainty is greatest when the scope is not known prior to the start of execution. This is the case for reactive organizations, such as Customer Support groups, which receive urgent requests that must be handled quickly, but which cannot be scheduled or planned in any meaningful way.

Another agile process, Kanban, is useful for this scenario. Kanban processes re-prioritize requests daily, and throttle (control) the flow of work by limiting simultaneous work-in-progress to a specified number (e.g., up to three concurrent requests can be handled by the staff).