5 Things that Must Be in Place to Get Accurate Project Estimations
5 Things that Must Be in Place to Get Accurate Project Estimations
Implementing these aspects will boost your capability to answer when something is going to be done
When is this is going to be complete? This is the most common and complex question to answer when you are executing a project.
Your team, the stakeholders and you, want to know when a project, or a feature, is going to be done and you need to have the ability to answer.
But which are the elements that must be in place that will help you get accurate estimations?
Imagine attending a coffee shop where you get your coffee really quick but it tastes really bad.
Then, you attend the next day to the same coffee shop, but they take too much time to prepare your coffee but now the quality of your coffee is supreme.
Since that coffee shop is pretty inconsistent, you will stop attending that place as you do not know what to expect. Most likely, you will find a place that gives you, a decent coffee, delivered in a reasonable amount of time.
What is the main difference that will make you choose another place?
Consistency.
The same applies to software development and IT teams.
But in order to get it, your teams need to:
Define the type of work your team does and the classes of service
Establish a common documented workflow
Determine your definition of Done (or Exit Criteria)
Form an stable and self-organized team
Clear requirements, consistent and manageable work items sizes
However, most of the projects do not have these basic elements implemented.
If you implement these aspects, regardless if you work under Scrum, Kanban, or any Agile project management framework or method, you will be able to gain consistency, and at the same time, be able to estimate the completion of any feature or project accurately.
But how do you implement these elements?
1. Defining the Type of Work Your Team Does
If we continue with the coffee shop example, some shops will serve only coffee, some others will also serve food. What they serve, will completely shape how the baristas will do the work, the way they deliver and even how the shop facility is arranged.
Just as our coffee shop example, not all the IT and software development teams deliver the same type of work and you need to make sure is clear and documented.
It may sound incredible, but many teams do not know if they just deliver software, do operations, production support or perform configuration changes or all of them. Therefore, the team is constantly confused.
The typical work item types I have seen on my teams are:
Stories, Technical Tasks (or technical enablers), Production Defects, Infosec Vulnerabilities, Bugs (typically non production issues) and Spikes
Tip: Make sure the teams also understand the hierarchy of the work item types and how they are grouped together. This is what I typically use:
0 Initiative (Months)
→ 1 Epic (Weeks/Months)
→ 2 Story, Technical Task, Production Defect, Bug, Vulnerability, Spikes (2 to 4 days)
→ 3 Subtasks (2 to 3 hours)
But determining the work items is not enough. Some product managers and teams do not understand how to prioritize the work coming into their pipelines especially when it comes to critical last minute changes or urgent issues. How do you manage these?
Defining the Classes of Service
This is a concept that comes from Kanban and will help your teams determine the sense of urgency and how we treat each work item that comes into our pipeline. You can use this regardless of the project management framework or method you use.
An Expedite work item is like an ambulance going into its own carpool freeway lane, one or more team members swarm to make sure this is done or resolved as soon as possible. Typically these are used for P1 incidents (e.g. production is down or the end customer is seriously impacted by a non working feature).
Tip: Be careful! There is a lot of temptation to have many things expedited and usually this happens when planning is not done properly. It is important to not abuse of this class of service, otherwise, if the majority of the work is expedited, your team will lose the sense of urgency and this will become meaningless.
A Standard work item is how we treat the vast majority of the work items using our regular sustainable pace to deliver.
A Fixed Deadline work item is treated with the same urgency as the Standard work items, the only difference is that it has a due date and it must be injected in the team’s backlog when needed. One example is if your team completes ten tickets per week in average and this must be done in two weeks, this work item probably needs to be in the 20th position of your backlog to make sure it is worked in the right iteration.
An Intangible work item may not be an urgent one and typically is work around technical debt, refactors or documentation that if we do not do, eventually, the cost of delay will be high. I recommend you to pay attention to these and inject some of these work items regularly into the team’s iteration pipeline.
Fine, you know your pieces of work, now it’s time to determine the steps required to actually do the work. What do you need for that?
2. Establishing a Common Documented Workflow
Imagine a manufacturing car facility and the people building those cars.
Now imagine that each of them follows different steps to build a car:
Maybe one person thinks that working with the chassis and attaching the doors first is the best
Another person may think that it is better to start classifying the electrical harnesses first
Or another person may think that we need to test each element of the car in separate before building the car
What will be the result?
A very inefficient and inconsistent process that is executed by each team member in a different way since there is not a common understanding across the team
This will lead us to reworks, defects and waste of time
Most likely a poor quality product and an unhappy customer
It is the same thing when building software. Your role here is to make sure your team get together to discuss, agree and document which steps need to be followed to convert the requirements into a working product.
Tip: have your team discuss how they are planning to move the code to production and the different environments they will use to test the code. Some environment examples and common names are: local ( this is the developer computer), QA, Beta environment, integration, UAT, staging, pre-production, and obviously, production.
My teams have determined multiple flavors of workflows and all of them are valid because they work for them.
Here are some examples:
Analysis > Ready for Development > In Development > Pull Request Review (or Code Review) > Testing > QA Validation > Deploy to Production > Demo-Acceptance > Done
Another example is:
To Do > In Development > Pull Request Review (or Code Review) > QA Validation > UAT/Design Review > Waiting for Merge > Ready for Production Deploy > Demo-Acceptance > Done
Tip: Make sure your Scrum or Kanban board reflects these steps to be a truly visualization and collaboration tool.
Although at this point the team may have a clear workflow, the teams may execute each individual steps in a different way or with a different level of quality, so there is still room for inconsistencies. How do we ensure the team delivers with the same level of quality?
3. Determine Your Definition of Done (or Exit Criteria)
Going back to our coffee shop example. The typical steps followed are:
1 Customer place the order > 2 quick beverages are prepared, served and delivered first > 3 more complicated meals (if any) are served later > 3 the client is called
Is not enough knowing the steps, as each employee in the coffee shop may execute the same step in different ways:
Maybe one employee does not heat the water at the right temperature
Maybe somebody else adds too much milk to the beverage
Make sure your team discuss, agree and document a checklist with the things they need to do on each step of your workflow. This will make sure that all work items that come into the team’s pipeline are treated the same way and with the same level of quality applied.
In Scrum this is called the Definition of Done and in Kanban the Exit Criteria of each step.
The idea is to create some checklist for all the steps of your workflow before you call a work item as done. Here are some examples for two steps:
Analysis step:
Tickets are analyzed and validated. Additional documentation is added to the ticket (if needed)
The ticket does not have any blocking dependency. The team understands the work item and has the necessary skills and knowledge to implement it
The team is able to break the tickets further and subtasks as needed.
In Development step:
Research or collaboration work is done (if applicable)
Code changes are done and it works as supposed to work as established on the Acceptance Criteria or the bug fix is done.
Testing in local is done
Unit tests are created and passed
Code is committed into a branch
The pre-checks ran and unit tests passed PR is created to be reviewed
We do not move the ticket to the next step until these checklists are complete.
Tip: Make sure to review your definition of done regularly as this may change overtime as your team may be more efficient or may introduce better and different ways to do things. I typically dedicate one retrospective session to do this.
Great! you have reached to a very good place now but that is not enough, as many team’s are not properly formed and they do not know how they want to work each other. How you can help your team to be aligned to do the work?
4. Forming an Stable and Self-Organized Team
Having a stable team is not an easy endeavor and even more in an IT world with a lot of attrition and constant organizational changes. You can apply these two things in order to do it:
Create a Comprehensive Onboarding Process
You cannot prevent people leaving your team. But organizing the knowledge and optimizing the process of onboarding new team members, ensures the entire team has a common understanding of how they work together and what they need to know.
Create a checklist for the new team members. These are some important elements:
The right accesses (e.g. repositories, wikis, systems)
Gather Readme files, manuals, documents or videos that will provide the essential information to get started
Ask your team to pick some good sample work items from the backlog for the new team member to work on first and to provide an idea of the software or the system you are building
Every time a new team member joins, do not assume that already knows how to work under an Agile or Lean mindset and the way your team does it. Give an Agile refresher session and explain the PM practices and the ways of working of your team
Ask the new team member to schedule a one on one with all the team members of the team to make sure everyone knows the new team member and for the new team member to ask specific questions individually
Create and Document your Team’s Working Agreements
Your team needs to agree on how to work together in a productive and positive way and one effective technique to help them do it, is to discuss and document the common understanding on how to do things as a team.
You can propose a list of aspects that you have observed and need to be improved for your team or you can use this list of aspects that I found are a common source of disagreements or misunderstandings:
Schedules:
Do they need to be available to each other 9am to 6pm? or are you working asynchronously?
Do they need to reinforce the availability on meetings or with the customer?
Do they need self-directed time for innovation or refine their technical skills?
Communication:
Do they need to reinforce openness or transparency?
Do they need to discuss better tools and ways of communication? (e.g. Slack, Jira comments, quick huddles, tagging, asynchronous Friday stand-ups)
Behavior and self organization:
Do you need to reinforce respect, accountability or foster collaboration?
When and how does your team picks up the work?
How do they want to organize themselves? (e.g. peer programming, team coding sessions, end of day tech discussions)
How does your team do coding and ensures quality? Some sample topics are:
Coding (e.g. the use of code quality tools)
Code reviews
Merging (e.g. branching strategies)
How to push the code to different environments
How they release and how often
Unit tests
Automated or manual integration testing
Do not force or impose any agreement, you may suggest and let them know your observations if there are some aspects not being covered:
“Team, I have observed that we are always connecting on weekends to resolve issues related to Friday releases to production. Do we want to discuss a different way to release so we eliminate or reduce the need to be connected on weekends?”
Keep the document simple and accessible to everyone with clear agreements on how the team wants to work together. This is a live document, so you need to make sure it is constantly reviewed and updated.
Here is a good website where you can find more guidance about how to build your working agreements.
5. Clear requirements
Following our coffee shop metaphor above, what will be the result if we attend the coffee shop and ask a coffee with no specifications? how large? with or without sugar? decaf?
If we do not specify, the baristas will serve you whatever it comes to their mind.
The same way, we should not start any software implementation without having a clear understanding of the work. The team must know who is asking, what is needed and why. You can use the user story format or any other that you think will work best for the team.
And do not forget to use an acceptance criteria. Is not the same asking for a “black coffee with no sugar” than “a large cinnamon roll Frappuccino blended coffee with soya milk”. We need to make sure that every work item has a written expected outcome. You can use the behavior driven development or the Given-When-Then format.
Tip: Remember to add references and images that will facilitate your team’s understanding of your requirements.
Why does your team need to understand the work? One important aspect is to know how big and manageable it is.
Consistent and manageable work items sizes
The team estimates a work item to know how complex and manageable it is. The estimation process helps the team start conversations about how to implement a feature or a bug fix and many interesting discussions emerge when this happens:
Are we breaking the work properly?
Are we discussing the work in the wrong priority order?
Do we have the knowledge and skills to do this work?
Are there any external dependencies preventing us to start this?
Which are the initial approaches for the team to resolve the issue?
Estimating is a controversial topic and I am convinced that once the team gets used to these conversations and they create work items similar in size, in my experience from 2 days and no more of 4 days of effort, you do not need to assign story points or t-shirt size estimations.
See the no estimates movement:
Do I need to estimate? My recommendation is yes if your team is just starting and they do not initiate any conversations when breaking and refining the work.
Estimation should never be an exercise of measuring work in hours and comparing people’s availability vs productivity. On the contrary, I always tell my teams that is just a ball park estimation exercise to know how big something is: S?, M?, L?, XL? and that’s it. Do not spend too much time and discussions on it.
You will realize when you ask for the size of a work item, the team will start asking questions and having technical discussions; that is the final effect you want get. You just need to ensure the discussions are productive and around the outcome and not the details about the “time” or hours it takes something to complete.
Bottomline, make sure your teams are mature enough to break the work into small and manageable chunks of work similar in size.
Why similar? so you know in average how much work they complete by week or sprint so you can extrapolate that to get fairly accurate estimations.
Why small? to ensure the team is giving value to the client sooner and in short iterations to get prompt feedback.
Conclusion
In summary,
Define the type of work your team does and the classes of service
So your team has a common understanding of the type of work they will get and they are consistent on how they manage the priority of the work.
Establish a common documented workflow
So the work items coming into your pipeline flow through the same steps.
This will reduce the misunderstandings and reworks. And will help you leverage visualization tools such as Kanban or Scrum boards to manage the flow of work efficiently.
Determine your definition of Done (or Exit Criteria)
So all the work items have the same level of quality and consistency.
Form an stable and self-organized team
So your team gain focus, motivation, continuous improvement and a sustainable pace.
Clear requirements, consistent and manageable work items sizes
So whatever coming into your team’s pipeline is understood, the unseen dependencies reduced and the work items are broken similar in size and are manageable.
Without any of these, your team will lose consistency, your process will have a lot of variation and it will be very difficult to get the proper estimations.
Hope you enjoyed this article! Let me know what you think in the comments. If you're feeling generous, you can buy me a coffee to fuel my writing!
Share this article if you liked it:
Subscribe to receive more posts: