Ship It! LIVEShip It! LIVE
home about services writing contact

We develop, test, and create fine software products, and design creative solutions to your problems.
The development of software is an intrinsically creative process. We are dedicated to improving our mastery of the art.
Links · RSS Feed
Popular Pages

They have gathered together the ‘best bits’ of various styles and methodologies they have been directly involved with, and combined them into a practical approach with the focus on delivering a pro...
-Mitch Wheat
...It would be really nice if, as an industry, we could stop being such a bunch of screwed-up clowns and start living up to our potential. Ship It! is one of the things that could help, if only tho...
-Mike Gunderloy
If your shop has trouble shipping quality software on time -- and let's face it, most do -- then this book is for you. If you're a manager, I'd say that doubly so.
-Ernest Friedman-Hill "JavaRanch Sheriff"

Minimum Viable Estimate (Dec 4)

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.

Category: Agile

A New Local Agile Conference: TriAgile! (Apr 7)
There's a great annual conference coming to RTP for the first time on May 2nd. The stellar speaker lineup includes:

And that's only about half the list! See the entire list here.

The conference has four concurrent tracks with six sessions, not counting Andy's morning keynote. We opted for shorter session times (45 minutes) with the hope we'd have more content and you'd get to attend more great sessions and hear more speakers.

We also worked hard to keep the prices low. A single ticket is only $99 and can be lower if you can bring 4 more of your friends.

Topics range from Tim Wingfield's Executable Requirements: Testing in the Language of the Business to Catherine Louis' Failure patterns: Lessons learned over 10 years transforming global companies. I'll be giving my introduction to agile talk. The material is wide ranging and I'm sure you'll have more than a few talks you'll want to attend.

Also, a huge shout out to Tom Wessel and all of Southern Fried Agile team. Without their help and backing, this event wouldn't have happened.

It should be a great first outing for this new conference. We're trying to spread the word, so please pass on the information to your friends and co-workers in North Carolina. I hope to see you at TriAgile!

Category: Agile

TriAgile in RTP (Mar 11)
I'm involved with a new conference coming to RTP in May. Come join us for TriAgile. We've got a great list of speakers and a good mix of topics. I'll be giving my Introduction to Agile talk. Andy Hunt, Cory Foy, and many other great speakers will share the stage.
Take advantage of the early bird pricing! I look forward to seeing you there.

Category: Agile

My Daughter's Flickr Page (Feb 12)
My daughter has been asking me to share her flickr page with my "nerd friends". So, my nerd friends, if you have the time to click through a few cats, dogs, and several "still life" shots from a budding photog, she'd appreciate it!
Main page
Her favorite shot of our cat
One of her landscapes
I hope you enjoy a few of them.

Category: Personal

Learning Backbone with Derrick Bailey (Aug 21)


I recently started doing video editing for the Pragmatic Programmers and the first title I worked with was an excellent getting started guide for backbone.js.

It’s not a sales job for why backbone is better, but rather it assumes you’ve already decided to use backbone and provides the information you’ll need to start using it. Derrick creates a slick image gallery application that uses backbone in the browser, and a bit of Sinatra server side.

Come check it out and I think you’ll be pleasantly surprised at how much you can do with it!

Hands On Backbone.js

Category: Misc

Next page
StarEast Testing Conference (2015-05-08)
The half day Acceptance Test-Driven Development tutorial
Better Software Conference and the Agile Development Conference (2015-06-08)
I'm giving my half day tutorial: Continuous Testing to Drive Continuous Integration and Deployment


© 2007 Agile Artisans.