Pages

Wednesday, July 04, 2007

Absolute estimates and Relative estimates

As soon as you ask any software developer about the effort it takes to implement a particular requirement, the answer would be either in hours or days. This is called absolute estimate and in the agile world the concept of relative estimate has been introduced by Mike Cohn(atleast as far as I know !).

In case of relative estimates, one would estimate the size rather than the effort relative to each other and then, this size could be mapped to effort based on the velocity/some other means. But the key thing is to understand the applicability of relative and absolute estimation techniques.

Story points are the units used frequently while applying relative point estimation technique.

Coming to the applicability part, the business people want to know how many days or months it would take to deliver the product. You can't tell them that the requirements takes 55 story points, these numbers may not help them to allocate budget or prepare themselves to market the product. They should always be given the absolute estimates. But, the route to absolute estimates at this point should be through relative estimates. This is because, as we move higher the abstraction the clarity reduces and accuracy with absolute estimates decreases. At higher abstraction levels relative estimates suit better than the absolutes. The maturity of the team lies in converting these relative estimates to absolutes and sharing with stakeholders.

Generally, product planning, release planning phases are at higher abstraction level than the iteration planning phase.

At iteration planning level, one has more understanding of requirements and can be more accurate in providing the absolute estimates.

Monday, July 02, 2007

Trends in Software Development methodology

Here is a good article about the changing trend happening around software development, what business people are thinking about software development methodologies and much more... Check out the following article

Thinking like Scrum Master

Most of the time our behavior/attitude would adjust automatically to suit a particular role or designation. For example, If somebody is a senior developer he would be spending time thinking only about solving a technical problem, he wouldn't worry or think about leading a team most of the time. His thinking gets limited to certain area of his responsiblities only.

Similarly, as one is promoted to become a project manager or Scrum Master, thinking patterns would automatically gets adjusted to lead the team and showing attributes of a leader. Fundamenally people wait for suitable title/designation and then would try to change their thinking patterns, atleast most of the times !!

Recently, Pete Behrens one of the Agile practitioner suggested a good thought in the Agile discussion group, and thought I would share here:

If you wait for a title to behave as that title you will rarely make it
there - rather if your act and behave what you want to become,titles become
some what irrelevant.