Ideal time in Agile estimation

In an earlier post we looked at agile estimation using story points. Let us now look at another unit used in agile estimation, the ideal time.

What does ideal time mean and how is it different from the standard calendar time used to come up with schedules and determine project completion?

The standard calendar time is also referred to as elapsed time. In this post, let us refer to this as calendar time since that is a term that is more widely used. Ideal time is what the term implies - the ideal time it would take to complete an activity if there were no overheads. To further clarify, overheads refer to the time spent on unplanned activities such as checking emails, phone calls, attending meetings, switching between tasks, interruptions of any kind, etc. which are very much existent in any team member's day. For example, in an eight hour working day, the ideal time available to work on a planned task may actually be between four to five hours after accounting for overheads.

When seeking time based estimates from team members it is important to be clear on the unit used. Are your team members estimating in ideal time or calendar time. When a team member says it will take X days to complete an activity or story, does it mean X days exclusively working on nothing but this particular activity? Managers who mistakenly think that any time based estimates refer to calendar days may map the estimate to a calendar and have the wrong expectation.

When estimating in ideal time the assumption is you will solely and fully work on the particular task for the estimated duration without any interruption plus everything you need (such as tools, people, dependencies, etc.) are readily available for your use when you need it. Ideal time estimates are agnostic to the level of overheads in a particular environment and may be used to derive duration similar to how Story points are used.

Story points & Agile estimation

An important element in agile estimation is the use of story points. Here's an overview of story points and their usage.

So, what are story points?

A story point is an abstract and relative measure of size of an user story. Estimating size in story points should take into consideration all of the activities (such as design, development, testing, etc.) required to complete the user story, plus the complexity involved, any uncertainties and risks.

What scale is used to assign these values? And, what do the story point values mean?

First, the story point scale is chosen by the agile/scrum team. It may be t-shirt sizes (small, medium, large, extra large, ...) or Fibonacci series (tends to have a good spread) or a series of numbers. The requirement is for the agile team to agree upon and have a common understanding of the scale. The values by themselves are not important. The relation of one value to another is of significance. For example, if we have a scale with values such as 1, 2, 3 and so on the expectation is that if a story is estimated to have a story point value of 2 it implies that this story is 2 times the size of a story that has a story point value of 1.

When we talk of estimating "size", the general confusion is to associate "size" with "duration" or "effort". An user story can have varying effort estimates based on the individual implementing it. For example, an experienced person may take 1 hour to do a particular job whereas a less experienced or fresh person may take 5 hours for the same job. However, despite the varying effort estimates, the size of the job does not change. Story points are a relative unit of measuring this size. The confusion around the three terms - size, duration and effort lead to these being used interchangeably when they actually are distinct entities.

Duration is a derived metric while we estimate size. Before getting into the how of deriving duration, let us look at another term - Velocity. Velocity refers to the number of completed story points per iteration or the sum of the story point estimates for delivered/completed stories in each iteration. For example if an agile team completed five stories in a particular iteration wherein each story was estimated at 4 story points, the total story points completed in the iteration would be 5 x 4 = 20 story points which is the velocity of the team. Since velocity can fluctuate for various reasons, it is advisable to consider velocity across multiple iterations to obtain a stable measure. To derive duration, sum up the story point estimates for all planned stories in a project and divide this by velocity. This number represents the number of iterations required to complete the planned set of stories. Given the number of iterations required to deliver the planned set of stories and the duration of each iteration, we can easily find out the schedule for the project.

Agile Planning

Does the term agile planning seem to be an oxymoron? Do agile teams really spend time planning? Well, actually they do. And the fact may be that agile teams actually spend more time planning than non-agile teams. OK, if agile teams indeed spend so much time planning, why isn't it evident like the planning done by traditional/non-agile teams? There’s a difference. And the difference is in the “when” of planning. Traditional teams focus on doing almost all of their planning upfront. Planning, or rather complete planning often precedes the “doing” in a traditional model. And by “doing” I mean the actual activities resulting in producing deliverables required by your customer. Contrast this with agile teams, wherein planning occurs throughout the project. So, how does this work?

At a fundamental level, agile planning acknowledges the existence of unknowns.

The upfront planning in agile is done based on what is known while acknowledging the existence of unknowns. With this limited upfront plan, agile teams jump right in to the “doing”. This approach enables agile teams to gather new information as they produce which in turn contributes to reducing the unknowns. New information gathered is used to revise plans. Agile planning is a flexible exercise that embraces adaptation of plans through the project as newer information is obtained and unknowns are progressively reduced.

Are unknowns important? Wouldn't an exhaustive upfront planning exercise clarify any and all unknowns? When we do not acknowledge unknowns we assume that the requirements available at the start of the project are complete and accurate, we (and our customers) know exactly what is needed and customers will not want any changes to defined requirements or add any other requirements. Even if we were to assume that the requirements are truly final, do we really know everything required at the start of a project to prepare a plan that need not/should not revised? Agile planning strives to iteratively and progressively reduce unknowns.

Agile planning is an iterative process of planning, followed by execution, (re)planning again while adapting to any new knowledge gained, then followed again by execution, and so on. In each iteration a working artifact is generally available to "show" customers or product owners (the ones who provided the requirements). Iterative planning enables clarifying any incorrect assumptions or estimates made earlier. 

Another aspect of agile planning is the focus on delivering features rather than just completing a checklist of activities. This enables bringing together multiple functions to collaborate in pursuit of delivering a feature or set of features in each iteration. An impediment in any area tends to impact everyone else and hence there is the joint effort in speedy resolution.

Agile teams plan at multiple levels depicted in the planning onion shown here.

Each level of the onion contributes to defining goals, setting time frames, ownership and resourcing for the level below. Agile teams are generally involved with Release, Iteration and Daily planning. 

A release represents a set of user stories/prioritized features to be produced and delivered as part of a new release. Release planning sets the high level goals for the release, time line, scope and resourcing. A release progresses through one or more iterations.

Iteration level planning looks at the stories/features to be delivered in each iteration (typically of 2-4 weeks duration). Daily planning looks at activities to be performed each day in pursuit of the goals for the iteration. Agile teams generally meet for a short stand-up meeting every day to discuss tasks performed during the previous day, tasks planned for the day and bring up any impediments that may be affecting their work. The other three levels - Strategy, Portfolio and Product are generally owned by Senior Management and Product Management.

Agile planning is about simplicity and flexibility. Flexibility to adapt to changing requirements and make needed course corrections in the plan. Does this flexibility mean that agile teams cannot commit to delivery dates? No. Agile teams are capable of providing realistic completion dates and actually meet them. When plans are changed, dates do not necessarily have to be changed. Changing scope of features, dropping non-essential or lower priority features, adding resources, etc. may be resorted to for maintaining dates.

Upgrade vs Migration

We often encounter these terms being used interchangeably and it is useful to point out a few differences. Here are some thoughts -

Upgrade is the process of moving an existing system from one version to a higher version. Normally, the term upgrade is used to refer to upgrading on the same hardware. This is also known as in-place upgrade. Upgrade allows you to retain your existing system, configuration/ device/ security/etc. settings. An argument against frequent in place upgrades is the possibility of reduced performance over time when compared to new installation and migration. Of course, doing an upgrade of your existing system carries the risk of rendering your existing system unusable in case the upgrade does not go as planned. To mitigate this risk, a full back up prior to upgrade is recommended.

Migration is the process of switching over or upgrading from one set of hardware to another. It normally involves installing newer software on a clean system and transferring data across. Migration can occur across versions of the same software product or even across software from different vendors such as migrating from SQL Server to Oracle DB for instance!

One of the uses of migration is in production deployments wherein you could continue to have your existing systems up and running while you perform a migration to another set of hardware. If the upgrade succeeds and your tests have passed, you can switch to the upgraded system. Else, you have the option of falling back to the existing system.

As testers, both these processes need to be tested. However, for organizations, which of these processes do they choose? The answer depends on multiple factors including - the feasibility of either of these approaches - can an in-place upgrade be performed/is it supported? Some systems may not permit further upgrades or your existing infrastructure may be inadequate to support an upgrade; next comes the need for an upgrade - do you need to upgrade? Assuming that upgrade is doable, it still does not mean that upgrade is what you must do. Is it really a must to maintain your existing infrastructure and do an upgrade or would it make sense to move to a new installation and migrate data across? Depending on the nature of the software you intend to move to, there may be many other considerations (apart from just the data) when choosing between an upgrade and migration.

The distinction between upgrade and migration isn't restricted to the above. Some organizations consider all of the above as different types of migration i.e. an upgrade is seen as an in-place migration whereas the migration listed above would be a non in-place migration. Yet other organizations view migration to a large degree as a type of upgrade (migration type upgrade) and distinct from migration itself with few differences. However, for simplicity's sake I have segregated upgrade (in-place) and migration as mentioned above.