Guide To Estimation & Planning In Agile Project Management

Project estimation is the first step towards making a robust project management plan. Project managers spend a lot of time and effort in carving out estimates and more often than not, these estimates just blow up as they hit the execution floors. So how is planning and estimation different in agile project management?

Before diving into the details let us understand the common estimation approaches that are prevalent across organizations. All project management teams end up with estimations that aren’t in sync with the ground realities of project execution.

Know the planning & estimation approaches with Orangescrum

Try it free

Why Is It So?

• Take a look at your last 3-5 projects and find out who did the estimation?
• Usually, it is an architect, a technical project manager or a SME, who will in fact will not be “executing” or working on these estimated deliverables.
• And then there is the “customer demanded deadline” which has no consideration of the actual requirements, project scope, resource management and or project schedule management.
• At times, even our customer facing teams are at fault where they over promise to get that crucial deal!
• Requirements aren’t finalized but an end date is!
• Clients and stakeholders keep changing the project scope frequently.
• Estimation was done with specific expert levels in mind and now you have to work with less experienced resources

All of these and many more such factors play a role in skewing your estimation and execution at the same time.

Then How Does Execution of the Project with Such Fragile Aspects Look?

• Lot of overtime
• Multiple reworks
• Questionable quality
• Mismanaged expectations on either sides ( customer and project team)
• Over stressed teams
• Low team morale
• Dip in CSAT rankings
• Escalations and withered client relationships

Does Agile Project Management Help Prevent All of the Above?

To a lot of extent, Yes!

And the question becomes, HOW?

Well, if you take a holistic look, you will find that agile projects are “value driven” as opposed to being plan driven!

Usually, in agile projects, the cost and schedule are kind of a given. For e.g. I have 6 months or 1 year to launch this project with $X.

Hence, the estimation isn’t directly in terms of efforts but in terms of value.

The value of each feature that must go into making the product or a specific service for that matter.

There is a healthy mix of strategic and tactical planning in agile project management.

Themes are at a more strategic level that cover the overall objective of the project so to speak. E.g. reduce product launch cost by 15%.

Epics are larger chunks of work that are a level below the theme to enable meeting the theme goal.

Stories are definite action oriented items from the end user’s perspective as how a specific product item, function or feature will be used.

Tasks are very tactical and granular breakdown of your user stories. They are the actionable items to meet the user stories!

So once the breakdown is done, how are they estimated?

PMI.Org has listed many agile estimation techniques. However, we will focus on 2 very simple and common techniques deployed by agile teams.

• T-Shirt Sizing
• Planning Poker

T-Shirt Sizing – As the name indicates, it is about sizing backlogs with very large items. And the terminology or measures are usually XS, S, M, L, XL & XXL.

The scrum teams get together for an open discussion on the backlog items and they usually consider the time (mostly in days).

Note that the T-Shirt sizing exercise is at a very high level and is non-numerical in nature.

The idea is to get the technical teams’ creative side out, have an open mind and more receptive of other team members’ view and way of looking at the stories at hand.

It works best for tams that are just starting out with agile project management.

Planning Poker – this is a more numerical way of agile estimation. I personally find it quite a pragmatic way of running estimations.

Basically,

• All team members participate
• Each member is given numbered cards ordered from 0-21 based on the Fibonacci series
• Once a story is read, each member holds the numbered card he feels to be the required efforts
• The outliers (the one with the highest and lowest numbered card) are called in to explain the reasoning behind their estimated efforts.
• This exercise is usually repeated till the teams are in sync and come to a common understanding of what efforts the story will actually necessitate.
• Over a period of time the teams get a sense of specific user story types and associated efforts.
• As agile teams hash out one story after other, their estimation gets robust, along with greater understanding of the project requirements. In more generic terms – a broader viewpoint!

Wrapping UP!

The main reason behind the popularity of agile project management methodologies like Scrum, Kanban etc. lie in the ability to simplify and work efficiently with uncertain requirements.

This comes from the approach to make iterations, release incrementally, test the waters quickly and finally – review & validate frequently.

The estimation done by the actual implementer is most important aspect

Agile is all about self-organizing teams and servant leadership i.e. offering teams greater freedom, accountability as well as authority to align & execute towards the project goal.

Value of each outcome – sprint deliverable helps shape the subsequent items from the backlog. Basically, there is increasing alignment between the perceived and delivered value.

Net result, unless the value of the outcome is greater than the effort, items from the backlog aren’t picked up for execution and ideally eliminated.

So, you also remove clutter with every sprint and your product roadmap becomes further robust and degree of uncertainty is reduced as well.

Shore up your agile estimation techniques & leave the uncertain behind with Scrum in Orangescrum! Start Today!