Release Planning and Schedule Monitoring : Myth or Real

In the previous post, we looked at the issues with estimation and for sure it’s clear that there is no way one can estimate accurately.

If you want to plan and monitor a release, the first thing one should know is the pace in which his/her team is running and the second is where we stand as of now. All the management care is if you cannot complete it tomorrow, when you can complete.

Obviously, one cannot go to their senior management and say it will be done whenever it is done. I am sure, we all need our jobs :).

Monitoring

But is that an excuse for the manager’s to sit idle and do nothing saying my developers are not giving any estimates or say I have got you an extension whenever you asked for. For sure, most of the managers rely on their techies to give the real picture. But isn’t that we all have some brain and we should put our brains to some use?

In one of my previous posts i have talked about my view points on this “Are we there yet?

There are two things one as a manager can implement, which can help him make informed decisions.

CYCLE TIME

As a manager one of the tools that can come handy for monitoring is the cycle time. Cycle time is the time that takes to complete a feature/story/task from start to end. Now classify your stories/features/tasks/whatever you have, in the format of small, medium, large, and extra-large.

Cycle Time

Calculate the cycle time. What one should be more interested is on the Average. Display your average time takes to complete the Features on a White Board. Build a Trend chart on the same so that everyone knows how things have changed (whether you are spending more time or less time) over the course of the development.

What if we realize that we are taking a lot of time to complete a feature?

There are two things one can look at.

  • How much time is spent at each section (Analysis / Development / Acceptance)
  • The Lead time to move a story from one section to another

This will give you the complete insight and all possible optimizations can happen after that. This will not only expose the problem within engineering team, but also the time spent in requirements. Say for example: If you see your team members spending most of the time in Analysis, i am sure you know where to optimize.

What are the benefits of doing this?

  • As a manager, one is not only dependent on the team to get the estimates. 95% of the teams are into brown field development and this will help big time.
  • Everyone in the team knows how much time approximately it takes to get anything done (since the average time and the trend chart has been displayed). If you are the Product owner, it’s easy to plan for releases by seeing the average time taken and the trend (whether it’s taking more time or less time).  Will it still be accurate? May be or may not be. But then you have some way to predict (using the Velocity Chart, Cycle Time and Cycle Trend) rather than just shooting at the dark.
  • Oh, this works for Brown field. But ours is Green field. Sure, you cannot change the estimates given. But even in your Green field you still need to plan for releases and this will be very helpful even in that case.

What are the downsides of it?

  • Project status will be crystal clear for all the stakeholders. People can make informed decisions.

VELOCITY CHART

Check this post from Johanna on creating project dashboards to display progress

Create the Line chart with Markers in Excel sheet which displays

  • Total Number of Features to be delivered in the duration of the project in X Axis and
  • Duration of the project (Week wise or month wise) in the Y Axis

Velocity Chart

(A Velocity chart for one of the projects i managed in 2009. This Snapshot was taken sometime around 26-Jul-09)

This will help you see the Features done on a week wise or month wise and the features left on a weekly or monthly basis. If there is a new feature or a set of features added on a specific period it will also show you a spike of the remaining features and anyone with common sense can understand what is going on in the project. If you need the project to be done on time, then most likely the Features done line and Features Remaining line has to meet in the middle.

What are the benefits of doing this?

  1. First, it gives a clear status on what is going in the project, how many features done, how many left and how many are newly added etc.
  2. Second, it helps the manager in clearly showcasing the changes that happens in the project. So no need to defend saying features added or modified is troubling the guestimate. In other words it helps in CYA…
  3. Third, the manager do not have to go to a techie to ask where they stand if he/she has to give a monthly update to the stakeholders.

What are the downsides of it?

  1. Project status will be crystal clear for all the stakeholders.
  2. Manager has to work. Apart from giving GYAN to the team members saying they need to be disciplined with their code, Manager also has to be disciplined in creating, updating and maintaining this which is quite some work. Of course, one can always find an executive assistant to do this. J
  3. Manager cannot blame someone else when things go wrong.

This sounds good. But how will it help me solve my estimation problem?

One may not get rid of the issue with estimates completely. But if this data is captured organization wide and have some way to classify data, you still have some scientific way to estimate rather than guesstimate  Of course, I do understand that every project is unique and the complexity varies.

An almost immediate thing which you can expect is

  • Oh, we don’t have such tools in our organization or project.  You don’t need a tool to do all this. You can do it using Excel sheet. Immediate response would be i don’t know how to create a line chart in Excel. All you have to do is type “Line charts in Excel” in Google and click “I am feeling lucky”. Of course one needs to read it which is beyond the scope of this post 😦
  • The other thing is oh, we are not agile. For sure, you don’t need to be agile to do this. Anyways most of us who claim that we do agile do not anything about agile.

IMHO, it is all about bringing in some discipline within the environment, and with a very minimal change everyone can gain.

Happy Learning!!!!

Image courtesy

ddpavumba / FreeDigitalPhotos.net

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s