It is common knowledge that people are bad at estimation. Engineers are particularly poor at it. They don’t account for overhead in their workflow, such as in-person interruptions, meetings, email and chat. When Victory CTO arrives on site to turn around an underperforming team, we must help the team provide accurate and actionable information to the business for both strategic and tactical planning.
Engineers give estimates in a vacuum. It is the responsibility of Project Managers and Scrum Masters to ask the right questions and report the right information to project stakeholders.
Victory must deliver a repeatable methodology for clients to follow.
Anatomy of an Effective Estimate
Victory’s CTO Practice often serves companies between 5 and 25 employees. These clients are usually in a difficult situation with key staff leaving, system failure and/or the inability to deliver meaningful customer value.
In over 80% of engagements, we find there is no process for setting strategic priorities and managing project based work. Often, work is not kept in an easily referenced form, but instead passes from person to person orally, via email, or in chat.
For clients to set technical team priorities, they need two key pieces of information:
What? - The aspirations for the customer experience and the impact on sales and retention.
How long? - A composite metric for dollars and opportunity cost.
In formal settings, “what” is referred to as “requirements.” This word “requirement” carries weight in its expectation of both precision and unchangeable nature. This is too much weight for most small businesses to bear. Instead, Victory asks stakeholders to write down their aspirations for the outcomes of a project, using as many pictures as they can manage.
Victory’s CTO practice works with engineering teams to create estimates in half-day increments that include development and testing time. We assume no automated software testing exists since this is the norm in 80% of engagements.
Further, Victory works with engineering teams to break a project down into smaller deliverables so that...
- Our client’s customers receive value more frequently
- Marketing has more reason to make exciting statements about features and fixes to client’s customers.
- Deadline risk is minimized
- If the aspiration is not a fit with the market, the project can be stopped and time recovered for the next priority.
Victory’s clients often have no project management capability within their own organization. Given we show up after trouble has started, we do not have the time - or the budget - to implement and train on formal project management concepts.
That is not to say we do not value formal project management, we simply value the client meeting their key goals more.
For this reason, we frame “what” is needed from a technical team as a desired outcome for a customer. This may look like a traditional Agile “User Story” but we don’t care how it is written, only that it is written down in a collaborative way. Google Docs and Office 365 are perfect tools for such collaboration.
The more pictures the better. Clever clients have:
- Drawn wireframes on a whiteboard. Annotated them in color. Taken pictures and put them in a doc.
- A minimal way to communicate intent and experience
- Written mathematics formulas on paper, take a picture and put it in a doc.
- A minimal way to express hard science without the weight of equation editors
- Used spreadsheets to generate example data for customer actions.
- A minimal way to communicate data dictionaries, test cases and future intentions for data without understanding data design and modeling.
The “clever” above boils down to getting a large amount of information written down in a collaborative way without having to master complex design, graphics, math and data tools. A picture really is worth 1000 words and those words have huge value to getting the estimates you need.
Victory helps business stakeholders communicate their aspirations to technical teams. In this way, technical teams return the favor by providing a more accurate time estimates for accomplishing the aspirations. Client’s executive teams are better equipped to plan strategically, and marketing teams can more effectively drive interest in the new features in the pipeline.
Estimates Provide Agility
In regards to strategic planning, Victory teaches teams to deliver the number of development-days and the number of testing-days. For tactical execution, we further break down the project into smaller, deliverable tasks with the same two metrics of “what” and “how long.” Stakeholders have more tactical control over the project and more strategic control over resource deployment.
Strategic estimation is done quickly and usually in service of annual planning. It is meant to guide the business in setting its strategic priorities for a given time frame.
From our premise, engineers are bad at estimating how long a task will take. To account for this we do three things:
- We only estimate on the ½ day
- We use a multiplying factor based on the number of tasks.
- We account for lack of automated testing with a multiplying factor.
Estimating a major initiative at the strategic level should take about two hours. Remember, this is for high level planning. Engineers will want to go down bunny holes around implementation details. Victory works to keep the conversation much more fluid by introducing quick activities like Estimation Poker if details begin to overwhelm the higher level objective.
Strategic Work Breakdown
*developmentTime=dayCount * (1.2+0.1*taskCount)*
Given a few pages of aspirations for a system, developers are tasked with breaking it down into deliverable pieces. These are then estimated in ½ day increments.
To account for poor human estimation skills, we then multiply the number of days (dayCount) by 1.2 plus 10% of the number of tasks (taskCount) that were identified.
So, if a project breaks down into 6 tasks, and the team estimates delivery in a total of 5.5 days. We would then multiply a dayCount of 5.5 by 1.8 in order to report delivery in 10 days. We always round up in deference to the adage, “Underpromise and over deliver.”
Known-Unknowns - Research Tasks
Known-unknowns are tasks the team knows must be done but does not know how to do. Examples might include upgrading a language or using a new cloud service for data storage.
Unknowns are the biggest risk to a timeline. As part of the breakdown process, Victory helps the team enumerate all of those which are known. For each such known-unknown, we include a research task as a deliverable. This increases the task count, thus increases the estimate appropriate to the number of unknowns.
Unknown-Unknowns - Why 1.2 as a multiplier
Unknown-unknowns are significant tasks that were not known to the team when the estimation happened. These often crop up in the middle of a project.
Example: A cool UI feature with dials showing a needle in a range of values.
The team believes the existing graphics library will support this, in which case it can be replaced without significant delay in estimated delivery. However, no such library exists and an extra day of coding is necessary in order to create one.
This is the reason for the 1.2 base multiplier. For small projects, the likelihood of a major unknown being discovered along the way is low, so the 0.2 extra will be very small. The larger the project, the more likely discovering new unknowns happens and the 0.2 will result in more days accordingly.
When we work with inexperienced teams we increase the multiplier. Junior developers don’t know as much about their ecosystems, so more is unknown to them. Senior developers lower this risk, thus the likelihood of a huge unknown cropping up is lower. Adjust this number by tracking estimate accuracy and the number of discovered unknowns after a project starts.
*testingTime = developmentTime * 0.2*
Finally, we must consider testing. Most Victory clients do not utilize automated testing methods. Therefore, we must rely on manual stakeholder testing. These stakeholders are busy, and we must account for delays in them getting to their testing duties, time to do the testing, and rework resulting from the testing. For this reason, Victory anticipates testing to add 20% to the overall project time. For example, our 9.9 day project is anticipated to take 9.9 * 0.2 or 1.98 days, of additional time for testing.
Since most of our clients have relatively simple software platforms, we use the 20% number. The more complex the system or platform, the higher the testing multiplier should be. Automated testing lowers the multiplier. Victory recommends no less than 10% testing time for stakeholder acceptance in any situation.
Reporting to the Business
In our example above, we would report to the business that the development team expects to take 10 days to complete the entire project and that we expect the business to spend 2 days testing for acceptance.
The business is able to take this information about the projects it expects from the engineering team and prioritize work, discuss its commitments to testing and provide direction to the company as a whole.
Tactical Execution Benefits
In small companies it is common for stakeholders to aspire to a project that has many valuable features to the customer. Some features are more valuable than others.
During the Strategic Estimation process described above, developers are asked to break down features into deliverables. Even though our project is going to take a total of 12 days, we want to deliver value to the end user sooner. There are beneficial side effects to executing these “value drops,” which we will discuss below.
Before project kickoff, stakeholders are asked to rank features from most important to least important. Work begins on the most important feature. It is tested and then put into production. Let’s say this took 2.5 days in our example above.
The benefits to the business
Victory clients have new value to message the user about in 2.5 days instead of 12.
Marketing has a reason to talk to customers through social media channels more frequently
Most Important: The business is getting market feedback on its aspiration before it has invested the other 9.5 days into the project.
Now, let’s assume that the client has announced the above new feature in its Facebook group. Users are generally excited, and we can see from platform metrics they are using it.
Stakeholders now know the next feature of the aspiration is likely to be a hit as well, and the development team can start. Morale on all teams is high because there is an expectation of success set by the consumer!
Two days later, in our 12 day project, the second feature goes to market. Feedback this time is lukewarm. Consumers tell stakeholders in the Facebook group that it’s just not that big a deal. However, this too, is a huge success!
The following features (and 7.5 days of work) are predicated on the adoption of the second feature. Before clearly wasting that time and money, there are three basic paths to explore:
- Stakeholders can re-evaluate the implementation of the second feature and have it reworked to improve consumer engagement. This leads to success.
- Stakeholders can determine that the following features in the existing project will make the second feature more relevant and continue as planned. This leads to success.
- Stakeholders can kill the project because logically it need not continue based on market feedback. Victory’s client has recovered 7.5 days of time for the next strategic priority. This is also a success.
If you are thinking to yourself, “This is the Agile Software Development Methodology,” then you are exactly right. Victory has simply put some guardrails in place around estimation and work breakdown. We initially removed much of the ceremony associated with Agile implementations like Scrum.
By assisting with creating stakeholder aspirations and engineering estimates, Victory provides critical strategic value to its clients through simple math. Our partner companies benefit from significant tactical advantages that allow them to place their resources of people, time and money on the right projects and delight their customers.
If you’d like two hours of complimentary consultation of your small business and its technical team, please contact Angela Miller.