Month: May 2020

Two Rules to Estimating Software Features

OK, you’re a software developer, and someone’s asked you to quick look at a feature, and give them an estimate on how long it’s going to take to develop. For this example, I will refer to that feature as ‘SuperFeature’, and we will have two estimating developer examples; Gina, who examples good estimates, and Lisa, who examples less good estimates. Priya is our product owner, and since Priya owns the product, good estimates give her the information required to make a intelligent decisions. Well-formed estimates enable her to prioritize work well, and manage expectations of customers and stakeholders.

Here’s two rules to estimating features successfully.

Rule 1: Your estimate should represent doing the ‘work done in a vacuum.’

It is counter-intuitive to estimate work in this way, but creating an estimate, as if that work is being done in a vacuum is the best way for your product owner to assign the feature a priority.

Example:

Gina, who estimates in a vacuum – “SuperFeature will take about 2 weeks to do.”

Lisa, who estimates based off of her current workload – “I will need 6-8 weeks to do this.”

In the first case, Priya knows how long the feature will take to develop. She knows that Gina and Lisa are both working on very high priority items, so she gets Liam to work on that feature.

In the second case, the Priya knows how long Lisa will take to get it done, but has very little awareness of the what priority Lisa is putting on the work. At next week’s stand-up, imagine Priya’s surprise to know that Lisa hasn’t even started work on it yet!

The lesson: Your product owner owns priority of the features. An estimate should give your product owner the information required to set that priority.

Rule 2: The larger an estimate, the more detail it needs.

If your feature is large, your product owner needs to know and understand why. In order to understand the work needing to be done, it should be broken down into tasks.

Example:

Lisa, who doesn’t break the work down – “SuperFeature will take about 4 months to work on.”

Gina, who realizes the work is complicated, and Priya needs to understand the details. – “In all, SuperFeature will take about 4 months. We’ll need 3 days to start building the catalytic converter, and then a week to refit and install the Whizzbang…” etc, etc.

In the first case, it’s hard to really even start the work, or even know how to break it up. Is it 4 months altogether? Can you break the work apart? Can you create multiple work streams?

In the second, Gina gives Priya all the details she needs to break up the work accordingly. She also does so succinctly, so that ordering tasks and dependencies are clear.

Following the two rules above will help make your estimates more valuable and your relationship with your product owner more beneficial.

5 months, abridged

Quite a bit has changed since my end of December post. The first two months of 2020 were a blur. {Redacted} went into a full change-over, a new CTO, and a new org structure early in the year, just as I had received word from a regional credit union that they wanted me to be their new, and only, Principal Software Engineer. I had to make a excruciating decision; to leave a company and people I loved, to move over to a new-idea-to-the-org position. Instead of building things and fixing things, I would be responsible for fixing the org’s developers and development processes.

One of the things I will take away is {Redacted}’s dedication to making the customer right, if there was a mistake or error.

Nothing is more freeing than the knowledge that, no matter the mistake, we will make the client right.

Knowing that we would always make the client whole allowed for experimentation and mistakes. Engineers are free there to do the best they can. There are many orgs who strive to be the very thing that {Redacted} has been.

Still, careers should not stagnate, and there was no place for me to go at {Redacted}. I had reached a space that the only place to go was if my superior retired or quit.

It has been three and a half months since I left, and I still miss everyone terribly.

Well, with the whirlwind of changes that occurred in February, naturally, a pandemic ensued which caused me to get a whopping three weeks of face-time with my new team. There are some outstanding people at my credit union, and with this past three months, I have been working to carve out my new-to-the-org role.

Some notes from the first

  1. Larger organizations have larger org problems. Each subteam has its’ own micro-climate.
  2. Empathy, empathy, empathy. You simply have to assume everyone is trying their best.
  3. TDD is nowhere near as ubiquitous as I assumed that it was.

On item three, I have been a TDD practitioner in spurts and starts since 2005, and I was later than I should have been to the game. It has simply been a part of a majority of the code I have dealt with. When folks describe it as new, it is a bit of a shock.

The elephant in the room clearly has to be the same thing everyone is dealing with. The big CV19. Here’s the high points.

  • My kids have been homeschooling since March.
  • My wife was furloughed from the Y, but still teaches the occasional ZOOM yoga course. We are blessed, in that the income from my new job covers what she was bringing in.
  • I do Crossfit at home, either on ZOOM, or simply by myself, and work from home completely. My outings are walking the dog, or going to the grocery store. I have visited a few wineries for club pickups, and recommend everyone go visit a local winery and support small business!

Stay safe!