DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • 5 Key Concepts for MQTT Broker in Sparkplug Specification
  • Replacing Apache Hive, Elasticsearch, and PostgreSQL With Apache Doris
  • Introduction To Git

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • 5 Key Concepts for MQTT Broker in Sparkplug Specification
  • Replacing Apache Hive, Elasticsearch, and PostgreSQL With Apache Doris
  • Introduction To Git
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Minimum Viable Estimate

Minimum Viable Estimate

Jared Richardson user avatar by
Jared Richardson
·
Dec. 26, 14 · Interview
Like (0)
Save
Tweet
Share
13.46K Views

Join the DZone community and get the full member experience.

Join For Free

As teams adopt more responsive software practices, one area is often left behind. We believe that the development team should deliver functionality incrementally. We know about minimum viable products. But, especially in larger companies, we hold onto the requirements until they are "done" or "right". Well-intentioned requirements groups work months getting work lined up for the developers and testers.

First, requirements, when done well, are an ever-evolving view of the product and the customer's needs. Trying to get it right in one go is like trying to ship your product in one pass. It's difficult to make anything perfect, especially requirements. The law of diminishing returns (and Little's law) kick in quickly. In other words, it's just not worth it. You'll spend far more money, and lose development runway time, by trying to perfect requirements.

I'd like to suggest we start thinking in terms of minimum viable estimates. This is not the completed estimate that's solid and can be relied upon. This is an evolving level of confidence. Understand and embrace continual elaboration and the Cone of Uncertainty. Initially we have a fuzzy idea, but it's gets better as we move forward. Here are a few steps your estimates might take.

  • Gut estimate. Or maybe rough estimate. This is an off the cuff, rough order of magnitude estimate. I don't want you to do any research or assemble a team. Tell me ~right now~ how big you think this work is. Maybe in quarter year increments. This requirement looks like one quarter for a team with this expertise. That one is at least four quarters!
  • Level 0 estimate. We've taken the requirement and broken it down to features. Here's how long we think it'll take, but we haven't gone too deep.
  • Level 1. Now your teams have broken down the features into stories. We're finally moving towards something with solid numbers behind it.


I usually find that gut estimates are much more accurate than anyone suspects, but we're not trying to be "right". We need to be accurate enough to do rough capacity planning as early as possible and engage development earlier. Are we within an order of magnitude of our capacity? Then proceed. Otherwise let's start reining in expectations from our customers, managers and sales teams. These stakeholders rarely get everything they want, but they don't realize that they won't until the proverbial 9th hour. I'd like to get them that information earlier in the process and help them understand that they really do have to sequence (aka prioritize) the work.

And now for the weasel clause.... :)

What are these estimates? We all know they ~aren't~ estimates. True estimates can only come from the team doing the work. Just like your general contractor would never schedule your house remodeling work without talking to the subcontractors that will do the work, you shouldn't try to plan without talking to your teams. These "estimates" are just enough relative sizing to get us started. They're based on our experience with other projects, but they are only starting the first step.

What's the point?

It's that the requirements process, just like development, can benefit from a bit of transparency and diversity. Teams can begin working with you on smaller slices of work when they understand where you're heading with the work.

Often teams can start working long before you think they can… but since they have no incremental visibility into your process, they can't tell you the requirements are good enough. One feature will be solid enough for a good team to get started. Others won't be. Open the blinds and let your coworkers help with the work. They might surprise you.

And finally, the team creating requirements require feedback. Are they doing the best job possible? Probably not… no more than your developers and testers are. So let them complete a small slice of work and get the teams that consume the requirements involved. They can say "This is GREAT! I love the way this feature is described and organized. It's perfect." They might also say "I have no idea what you mean for this area… please don't write another 150 requirements this way!"

A tight feedback loop will enable your team to continually improve the process. Working without feedback rarely leads to the best product you are capable of producing and never builds a team. Involving your technical teams earlier helps the work become something you all own, instead of commandments handed down from on high.

Never forget that over 70% of our work is rework due to wrong requirements. Having another team of eyes with a different perspective will drastically improve quality.

Start with a more imprecise gut feel with rough epics and features. Involve your technical coworkers earlier. Don't be satisfied with a big bang requirements process. You'll be amazed at the effectiveness of a minimum viable requirement.
teams Requirement

Published at DZone with permission of Jared Richardson, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • 5 Key Concepts for MQTT Broker in Sparkplug Specification
  • Replacing Apache Hive, Elasticsearch, and PostgreSQL With Apache Doris
  • Introduction To Git

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: