As a preface, this is not a revolutionary concept or idea. Still, I believe it’s something that can be really useful, particularly for people starting out in management roles.
While agile methodologies, like Scrum and Kanban, have many advantages when working on projects with a lack of clear product definition, they can fall short in some areas. One of these areas is time estimation for a defined feature. First, a little bit of context.
A good practice for creating user stories is to follow the "INVEST" methodology.
In my experience, it’s sometimes difficult to keep all stories independent of each other. If the product requirements are defined late and the deadlines are tight, there will likely be dependency amongst the stories. This is where the critical chain method can help alleviate some of agile’s shortcomings in these particular cases. I’ll only be using some of the concepts related to critical chain, the ones that have been helpful to me in past experiences. The end result doesn’t follow the critical chain method exactly, but it does borrow here and there from the chain.
Let’s say we get requirements for a feature that needs to be developed by our team and we get a deadline that has about 2 weeks of wiggle room. The first step is to define the amount of human resources that will be working on this feature. Do we have enough people on the team or do we need more? To learn some techniques on developing new talent click here.
The second step is to break up the complete feature into user stories, which could be estimated in time (commonly measured in hours) or in points (using the Fibonacci scale is relatively common for this). It is helpful to have a team meeting to review the user stories and to estimate them using whatever methods the team deems appropriate, let’s call this step number three. The key thing is to have a way of knowing the level of complexity or time needed for all of them.
Once all of the above has been done, it’s time to start identifying dependencies. If there are any, step four would be to create different chains with all the stories that depend on another one. Having done this, the critical chain can now be defined. If the user stories are estimated in hours then the final estimation for time needed will have a greater chance of being more accurate. If stories are estimated in points, it isn’t the end of the world. While there is no direct equivalency from points to time, higher pointed stories tend to take longer than lower pointed stories. Here the manager of the team can use the team member’s individual velocity per sprint to guesstimate how much time the stories are likely to take.
Now, with the chains identified, the human resources available defined and their average velocity per sprint calculated, is when the critical chain can be singled out. This would be the fifth step. The critical chain, being the chain that needs the most time to complete, will allow us to see if the deadline can be met or if more time has to be negotiated. If the deadline can’t be met and there are human resources available that could help us meet it, this is where the team’s size can be adjusted.
The beauty of this method is that as time progresses we can see if we’ll be able to finish on time. If we have all the chains identified we can know if we’re doing good or if we’re running behind schedule at the end of every week or even every day. There is no need to wait until the last stretch to see if we’ll make it. This allows for progress to be crystal clear. The development team, management, the client, the stakeholders and just about anybody, can use the critical chain as a point of reference to know if the feature will be completed on time.
All of this has a positive impact on everyone’s spirits. It can help keep the relationships with the client/stakeholders in good shape because of the high degree of transparency and the fact that we can let them know early in development if we’re on time or not. It can also help improve the development’s team morale because late nights and stressful ends to the development cycle can be avoided, or at the very least, they can be known in advance.
To learn about our tech leadership advancements and find similar articles visit our specific leadership page.
