How to Estimate Big, Scary User Stories

Let’s talk about how to deal with stories that are hard to estimate. (If you’re interested in a broader discussion of Agile point-based estimation, check out this post over here.)

In every backlog I’ve estimated, I can recall running into a handful of stories for which I had no idea what point value to assign. I’d usually be using the following scale: 1, 2, 3, 5, 8, 13, 20, 40, 100. Most of my estimates would fall in the 1-13 range–nice and concise. I could feel a pattern coming together directing where every story would fit. Each one would take about the same amount of time to discuss. And then… Read more on How to Estimate Big, Scary User Stories…

Less Is More – 4 Benefits of Starting with a Minimum Viable Product

Eric Ries defines a Minimum Viable Product (MVP) as

“…a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

An MVP usually targets early adopters and includes only the minimum amount of features to validate your value proposition hypotheses.

A Caveat

The practice of starting with an MVP is a lean startup tactic. To execute an MVP well, I suggest you study the principles behind it and the Lean Startup Methodology as a whole. Understanding Lean Startup principles will also be a great help as you build your company.

When Less Is More

Through years of experience helping clients build products with Atomic Object, I’ve found most product managers and entrepreneurs tend to overbuild their first product release. This is often comes from a fear of underbuilding – they want to know that they’re product is compelling enough for their users, and they don’t want to give competitors a chance to leap-frog them. I also believe overbuilding can be partially motived from another fear — a subconscious desire to put off the release and the prospect that your idea might fail.

Read more on Less Is More – 4 Benefits of Starting with a Minimum Viable Product…

An Operations Mindset Is at Odds with Innovation

Atomic Object has helped many companies design and implement new software products. I’ve noticed different environments at companies that are primed for innovation and companies that are not.

Operational Mindset

Roger Martin’s knowledge funnel concept describes how business practices become more algorithmic as organizations scale and strive for efficiency. As companies scale, their technology departments develop an operational mindset and become more focused on efficiency and stability than on creating opportunity.

The Knowledge Funnel from Roger Martin’s “The Science of Art and Business”
(Originally published in Rotman Magazine, Winter 2009.)

Read more on An Operations Mindset Is at Odds with Innovation…

Fixed-Budget, Fixed-Scope, High-Quality Custom Software

Atomic creates custom software for our clients. Our work ranges from greenfield web application development to creating backend data-centric applications. In most projects, we work with multiple technologies and we integrate with other systems. We’re not experts in every technology, but we’re experts at becoming experts with any technology we work with.

Read more on Fixed-Budget, Fixed-Scope, High-Quality Custom Software…

Spending Too Little Is Worse than Spending Too Much

It’s much worse in a custom software development project to spend 80% of what you need than it is to spend 120% of what you need. You can understand this better by doing a simple thought experiment.

You have a project in mind. You think you know the revenue it will drive or the expense it will reduce. To understand whether you should do the project, i.e. whether the return justifies the risk, you need to know how much it will cost to build. To know that, you need to know the future. The problem is, the future is tough to know, particularly in new product development.

Thought Experiment

Project yourself a year into the future. Your product is complete. It’s generating revenue or reducing expense. You’ve found El Dorado. You got to this point because you worked closely with your team, you got to market quickly and learned from your customers, and you adapted your product as necessary. You may have built a few features that aren’t used much, and you might have spent a little bit of time and money on decisions that you later reversed. But by and large you got where you wanted to be pretty efficiently.

Read more on Spending Too Little Is Worse than Spending Too Much…