Scrum

Point of abstraction

September 8th, 2011

A scrum point is an abstract unit of complexity of a user story. For developers, this concept usually takes a while to get accustomed to. Instead of estimating in development time, developers are asked to estimate a story’s complexity in terms of another reference story, which is commonly assigned 3 points.

This definition makes a point seem abstract since it does not have any unit of measure. For instance an estimate of 1 point does not mean the story will take 1 hour, 1 day or other conventional units of time.

How deep does the rabbit hole go?

September 2nd, 2011

Fibonacci numbers is a numerical sequence in which each new term is the sum of the previous two. It starts like: 1, 1, 2, 3, 5, 8, 13 …. This sequence found a new use. Scrum practitioners started using it for estimating user stories under the premise that the larger the story the less precise is the estimate. Since the distance between Fibonacci numbers grows, it implicitly builds margin of error in.

I worked on several projects where we used Fibonacci numbers for story estimation and I disagree with the idea of using this sequence. I do not think it provides any benefit.

The Art of Estimation

December 8th, 2010

I interviewed a number of project manager candidates recently and one of my favorite question was how they do estimation. A common response I got was that people would estimate a task/deliverable based on past experience, speak with tech leads, architects and various business stakeholders. Very seldom do I hear people mention that they would consult with the developers who would do the actual work. Another extreme would be that end users or senior management would set an end date and dictate scope, then Project Managers would reverse engineer the date to come up with estimates.

Collabnet (Danube) Certified Scrum Master Course; London

June 8th, 2010 / Objects of Distraction

Last week I attended a Certified Scrum Master course. I was keen to gain perspective on the role of a Scrum Master; specifically coming from a testing / QA background, I wanted to understand who ‘best’ fitted the role. Going into the course, I had the pre-conceived idea that Developers were best suited to operating in this role; as if the team raised blockers during a stand-up, they are likely to understand the problem and be better placed to work towards a solution.

Sometimes bed is not an option

June 7th, 2010
Sometimes bed is not an option

Sometimes bed is not an option

How many times do you hear that to do the right thing is “Not an option” because of your client engagement.

I sometimes suspect this is much more driven by fear of the engagement than by the actual need – Sometimes being unpopular is the only option. Let me illustrate a fairly common scenario for you.