Our Favourite Activities That Assist Our Estimation Process

SOFTWARE DEVELOPMENT

Did you know that about 65% of the world’s pop­u­la­tion are vi­sual learn­ers? This means that we (and yes, I would def­i­nitely clas­sify my­self as a vi­sual learner) are more likely to grasp ab­stract con­cepts and ideas faster and to a higher ex­tent us­ing vi­sual aids.

Visual aids do not nec­es­sar­ily have to be some­thing a per­son can see and touch, they can ab­solutely be some­thing that they can imag­ine.

In soft­ware de­vel­op­ment, there are many ab­stract con­cepts and terms that are pre­sented to Product Owners. Due to their ab­stract na­ture, at times, it can be chal­leng­ing to un­der­stand every­thing.

It goes with­out say­ing, that be­cause we are the soft­ware de­vel­op­ers, we should hold the knowl­edge for all those bril­liant con­cepts, but we do need the abil­ity to ex­tend that knowl­edge to our Product Owners, es­pe­cially when it comes to es­ti­ma­tions.

Estimations, as we have seen in our blog, “How ac­cu­rate are soft­ware es­ti­ma­tions? Traditional vs Scientific Estimates,” in­volve a few dif­fer­ent ap­proaches to this as­pect of build­ing cus­tom soft­ware.

In a per­fect world, es­ti­ma­tions would not be re­lated to con­tract dates and billing but rather as a tool for the prod­uct owner to pri­ori­tise the back­log.

When we es­ti­mate, we are dis­cussing the size of the scoped pro­ject bro­ken down into its in­di­vid­ual user sto­ries, or epics. Epics are large sec­tions of work that can be bro­ken down into mul­ti­ple sto­ries (or tick­ets, is­sues, etc. de­pend­ing on the pro­ject man­age­ment tool you are us­ing).

Think of it as a fea­ture or a page of an ap­pli­ca­tion. For ex­am­ple, the abil­ity to cre­ate and sub­mit a post on a Facebook wall is an epic. Then, all of the el­e­men­tal items within that such as text in­put, graph­i­cal at­tach­ments and hash­tags (plus so many more) are all sto­ries within this epic.

Each of these vary in size and com­plex­ity. The is­sue here is not­ing when some­thing is seem­ingly sim­ple but in­her­ently dif­fi­cult and be­ing able to con­vey that com­plex­ity in a mean­ing­ful way to the Product Owner.

So, what do we do?

Introducing… ac­tiv­i­ties!!!

We run es­ti­ma­tion ac­tiv­i­ties to vi­su­ally, or metaphor­i­cally, rep­re­sent the size user sto­ries are. Think back to that pop­u­la­tion break­down of vi­sual learn­ers, 65% (!); we want to ease the grasp­ing of this ab­stract con­cept as much as pos­si­ble, so we use vi­sual aids.

In the WorkingMouse scop­ing teams we have a prod­uct de­signer and a prod­uct de­vel­oper who fa­cil­i­tate these ac­tiv­i­ties.

Due to their sub­ject mat­ter ex­per­tise, I turned to them to help me flesh out the fol­low­ing ques­tions:

  1. What are the ac­tiv­i­ties we run?
  2. Why we do them? And,
  3. Do we have a pref­er­ence as a com­pany?

The es­ti­ma­tion ac­tiv­i­ties we run at WorkingMouse

1. T-Shirt Sizing

What is it?

This ac­tiv­ity gives con­text to the size of the user sto­ries that make up the en­tirety of the pro­ject. Each user story has an as­so­ci­ated T-shirt size (i.e. S,M,L, etc.) de­cided by the scop­ing team.

Why do we do it?

It is pretty easy to imag­ine the size of a t-shirt in com­par­i­son to other t-shirt sizes. It is also a great con­ver­sa­tion starter be­cause some­times, some­thing seem­ingly small is ac­tu­ally re­garded as a large item.

For ex­am­ple, sin­gle-sign-on (SSO).

SSO is very com­monly used across large ap­pli­ca­tions. For con­text, SSO is when you can jump onto an ap­pli­ca­tion (either web or mo­bile) and you need to cre­ate an ac­count, a few op­tions might pop-up to use to cre­ate this ac­count. These op­tions could be (but not lim­ited to) your Google ac­count or Facebook ac­count.

These SSO op­tions make the ac­count cre­ation process more ef­fi­cient, but also make the re­turn­ing user ex­pe­ri­ence so much bet­ter.

So go­ing back to our t-shirt siz­ing. Even though the user work­flow for SSO is quite short, sharp, and sim­ple, lead­ing you to be­lieve it will be a small t-shirt size, the ac­tual in­te­gra­tion with these ac­counts is quite com­plex.

Hence, the shirt size is large to con­tex­tu­alise the com­plex­ity.

Using this ac­tiv­ity is great on a story-by-story ba­sis but is also a great way to show the size of the over­all pro­ject. The prod­uct de­vel­oper can demon­strate the size of the pro­ject by group­ing all of the user sto­ries and their sizes to­gether, and the prod­uct owner can fol­low along at a high level.

Think of it this way: a pile of laun­dry con­sist­ing of all large t-shirts is go­ing to be larger than a pile of laun­dry con­sist­ing of all small t-shirts. So, if you only have a small wash­ing ma­chine, you are go­ing to pri­ori­tise what can go in that load! Meaning you may pick the most im­por­tant shirts to wash first.

To round out this laun­dry metaphor — the wash­ing ma­chine, is the bud­get/​time­frame…i.e., what the prod­uct owner has spec­i­fied are the con­straints the pro­ject must op­er­ate within.

2. Fibonacci

What is it?

Taking you back to your pri­mary school math­e­mat­ics class, this se­quence demon­strates the con­stant ad­di­tion of num­bers us­ing the pre­vi­ous. 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55…etc.

We use Fibonacci num­bers (or se­quenc­ing) to help us man­age the er­ror in our es­ti­ma­tions.

We need to re­mem­ber that es­ti­ma­tions are, by de­f­i­n­i­tion, al­ready in­cor­rect pre­dic­tions of the fu­ture. They are es­sen­tially well-in­ten­tioned guesses.

As such, be­ing too spe­cific with our es­ti­ma­tions can re­sult in a larger er­ror rate due to the in­herit in­ac­cu­ra­cies within the es­ti­mates. We need to give our­selves a buffer mar­gin.

What we gen­er­ally want to know is rel­a­tive ef­fort of the work. We can then de­fine a base­line for a well-known item of work (i.e., some­thing that we es­ti­mate at 2 hours is gen­er­ally very well un­der­stood) and mul­ti­ple out by our fac­tors.

For ex­am­ple, Ticket A is at least twice as much work as Ticket B.
Ticket B may be 2 hours; there­fore, Ticket A is es­ti­mated at 4 hours.
It is much more chal­leng­ing to be able to say, Ticket A is 1.3 times as much work as Ticket B.
…Thus, Fibonacci.

Why do we do it?

Similar to t-shirt siz­ing, this is a way to rep­re­sent the com­plex­ity in each of the user sto­ries in com­par­i­son to each other.

Additionally, as I quickly men­tioned above, this se­quenc­ing pat­tern al­lows for us to fac­tor in mar­gin of er­ror, or, more specif­i­cally, risk. It is in­cred­i­bly im­por­tant to note that there is an el­e­ment of risk with every­thing we de­velop.

This is­n’t meant to scare any­one off, risk is as­so­ci­ated with every­thing. The cru­cial fac­tor here is what we do with that risk and how do we sci­en­tif­i­cally ac­count for it.

At WorkingMouse, we have formed, it­er­ated on and con­tin­u­ously im­proved our risk fac­tor cal­cu­la­tion process. This is cal­cu­lated as a mul­ti­pli­ca­tion of the com­plex­ity and the un­fa­mil­iar­ity of each user story.

Sure, a cal­cu­la­tion is math­e­mat­i­cal there­fore it should be cor­rect, but the key to re­mem­ber here is that the fac­tors that make up our cal­cu­la­tions are es­ti­mates and there­fore should be con­sid­ered as an es­ti­mated cal­cu­la­tion.

3. Poker Cards

What is it?

“Show me yours and I’ll show you mine” is kind of the con­cept we are go­ing with here. The idea is that we in­volve an ob­jec­tive third party (usually an­other prod­uct de­vel­oper) to es­ti­mate the pro­ject along­side the scop­ing prod­uct de­vel­oper.

There is not much col­lab­o­ra­tion here un­til the es­ti­mates are com­plete. What we want to achieve is con­sen­sus be­tween the two de­vel­op­ers that is­n’t blind-sided by con­text.

Firstly, the team uses some time to dis­cuss and get a bet­ter un­der­stand­ing of the ticket and any risks or as­sump­tions, with­out men­tion­ing any es­ti­ma­tion num­bers so es­ti­mates aren’t bi­ased.

Once the team has dis­cussed this, it is time to es­ti­mate. Usually us­ing num­bered cards, each de­vel­oper will choose a card (or write a num­ber down), and re­veal their es­ti­mate si­mul­ta­ne­ously.

Why do we do it?

Realistically, we don’t al­ways have the time al­lowance to com­plete this es­ti­ma­tions process - it can be a pretty lengthy process. In say­ing this, the process of en­gag­ing an­other prod­uct de­vel­oper to ‘sense check’ the es­ti­ma­tions is some­thing we do carry out.

So, what do we do at WorkingMouse?

A good sci­en­tist does­n’t rely on one method, they have an ar­ray of method­olo­gies to get an an­swer they are sat­is­fied with. Therefore, we don’t nec­es­sar­ily have a pre­ferred method of the above (or of the nu­mer­ous oth­ers that are out there). We use a com­bi­na­tion, or at least the favourable el­e­ments, of the above to de­ter­mine the most sci­en­tific es­ti­ma­tions pos­si­ble.

Because of this tan­dem method, we use the same process across all of our pro­jects. This is the best way to en­sure con­sis­tency, pro­fes­sion­al­ism, and con­fi­dence. You can read more about our spe­cific process on the Scope page of the Way of Working.

Estimating a pro­ject is a heav­ily in­volved process, but with the right team and process, it can be a suc­cess­ful ven­ture.

Discover Software
Secrets

ABOUT THE AUTHOR

Alice Spies

KPI mo­ti­va­tor and res­i­dent head chef

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion