I could fix keyboards

I got my first computer when I was 20 years old (a late bloomer) back in 93. At the time, if a keyboard stopped working, I could fix it. It was no big deal, most of the people I knew could do it to. Troubleshooting the problem was easy.

Open the thingy and look inside.
If it's dirty: Clean it.
If a piece is loose: Push or bend it back in place.
If a piece is visibly broken: Make a new one or replace it with part from another dead thingy.
If a circuit was visibly burned: Replace it with the same part from another dead thingy or declare that one dead but keep it for the parts.

With this check list, you were able to go a long way before throwing something away. So I kept on fixing keyboards, mouses, laptops and PCs for years. Then one of my Natural-Keyboards broke. “No problem!” I was thinking, getting my tools out. It's been a long time and couldn't wait to see what it looked like inside. It was a shock. There's nothing in there. It was two pieces of clear plastic sheets, one of top of the other, covering the space under all the keys. Imbedded in the plastic is a bunch of circuits lines and by pressing the two plastic layers, lines on each layers would form a contact. It was not dirty, there was no pieces to get loose and it was not visibly broken or burned. I was screwed. 'So long' my 120.00$ keyboard and 'Hello' the cheapo 19.99$ keyboard. Yet another reminder of to the consuming world.

Nowadays if something breaks, most of the time we throw it away. If we bother to open the thing, it often brakes in the process since it's not meant to be opened. Once inside, we look at the one chip that, somehow, does everything in-there and sigh before throwing the pile of pieces in the garbage.

I like to fix things. Most of our tables, desks and cupboards in the house are nice old things having a second life. Not that long ago, my wife came home with an old sowing desk that we turned it into a side table in the living room. While fixing it I remove the sowing machine pedal that was still attached inside the desk.


It was begging me to open it and so I did.


It was simple swivel harm that could make contact at five different places on one long coil resistor, or be in the 'fully on' position or the 'fully off' position.


I had a mixture of emotions. I started by being impressed with the simplicity. I knew I could fix that and I knew I could use that design in an eventual project. I was also angry that things are not made like that anymore.

Points vs Hours

The pains of task estimation. It makes that warm feeling of starting a new project disappear completely. No matter what's your method, Waterfall or Agile, you have to tackle that features list at the beginning of the project and estimate like there's no tomorrow. It's always too big and all those estimations will enable the team to scope. And so, you get to it. It take all of your team days to get through it and a the same time you know you'll have to re-estimate all of those features throughout the entire project.

I got tired of that. Not fast enough, but after 16 years of estimating with hours I couldn't face another project like that. That's when I gave a good try to the Story Points system. It appeared a bit suspicious so I 'googled' away on the subject. My goal was to find THE reason that would convince any programmers on my team to switch to a points estimation. Lucky me, I found one and here it is:

Behold the one reason to use points over hours when estimating.
>> If you show two different features to two programmers, chances are they will not agree on how long, in time, it would take to code it. They will, on the other hand, always agree on which task is bigger than the other one. <<

It takes us now 2-4 hours to estimate what took us a full week before. Here are the easy steps:
1) Put all the possible stories in a spreadsheet.
2) Create a second spreadsheet that will contain, in the end, your estimated backlog (aka the list).
* In this list, the big stories will be at the top and the small ones at the bottom.
3) Copy the first story into the list. Since it's the first item, just drop it at the top of the sheet.
4) Copy the next story into the list by doing an insertion sort based on the simple question “Is this new story smaller or bigger?”.
5) Repeat step four for all the stories.
6) Giving points to the stories starting at the bottom of the list, by giving the first one 1 point.
7) Using the Poker Planning scale (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100), ask yourself if the story above the last one is in the same scale.
* If it is: Give it the same estimate.
* If it's bigger: Give it the next increment in the scale.
* If it's smaller: Move it down until it fits.
8) Repeat step 7 for the entire list.

Tips:
- Try to make most of the list fit between the included values 1 and 13.
- Sometimes micro stories are at the bottom of the list. Give them the value ½.
- At the top you will probably find some Epics of values 20, 40 and even 100. those will have to be broken down into sub stories latter.

Those stories will never have to be re-estimated unless the descriptions changes dramatically. The velocity of the team can be calculated by the total of points they can burn in one sprint and that velocity normally stabilize after 2-3 sprints. With that value you can also predict how many sprints it will take to complete the backlog.

Go points!