How to Estimate and Deliver Software Projects (Part 2)

Understanding the Goals Behind Estimation

Written by Mike Piccolo, CTO

Not spending sufficient time to fully understand both the requirements and the goal behind the work is one of the biggest mistakes developers make when estimating. Often they will look at the technical aspects of a particular story or feature and ignore the business or project concerns that underpin the motivation for the story in the first place. Other times they will do a cursory scan of the story without diving into all the details particular to that project. Estimating is difficult enough when having a full grasp of the scope of a story, not having this knowledge makes it even more difficult. Therefore, the first step to providing a realistic, achievable, and accurate estimate is to spend the necessary time to fully understand the story’s requirements, the goals behind the story, why the story was prioritized, and why the story was assigned to you specifically. I call this goal-based thinking. The following will cover goal-based thinking in a series of steps that must be completed before providing an actual estimate.



Step 1: Identify stakeholders


Stakeholder: A person, group or organization that has an interest or concern in a scope of work.


For any given scope of work, you will need to ask yourself:


  1. Who is asking for this work?
  2. Who will this work impact?
  3. What role do they play in the organization (CEO, employee, customer, partner organization, etc.)
  4. How will they be affected by completing this project?

Asking these questions will help you understand the goals behind the project. Many developers assume that the product owner or customer is the stakeholder, but this is a mistake that will lead to problems down the road. If the true stakeholder is the CEO of the company then they will have a very different set of expectations for the work than the product owner. If the stakeholders are end-users of the product as well then they will have very different expectations for how the software should look and feel. If the product owner is pushing for certain changes that do not fit with the vision from the stakeholders, this might cause problems down the road. Identifying who the real stakeholders are will help you make better decisions about the product and ultimately how work should be estimated. Let’s walk through a scenario and see if we can identify some stakeholders.


A product owner asks if you can help him build a new workflow for an accounting system. They give you the high-level overview: “We would like to create a workflow that allows our accounting employees to add invoice payment details into our system.”


Let’s answer the questions provided above:


  1. Who is asking for this work?

    The product owner is directly asking you for the work but who is asking them to ask you? Turns out with a little more digging you find out this request came from the CFO of the company.
  2. Who will this work impact?

    We already know who this will impact directly. It will impact the accounting employees who will need to be trained in this new workflow. What else is involved for these employees? After asking further questions you find out that with this new workflow, they will no longer need to duplicate data in two different systems. The CFO has found many cases where the data is not matching up between the two systems and is causing major issues with their clients. It appears that several of their large clients are very unhappy with the discrepancies in billing and are threatening to leave the company. The CEO moved this to top priority and made sure the CFO is focused on fixing the issue.
  3. What role do they play in the organization?

    So now we have these stakeholders identified:
    • CEO: Needs to ensure that he retains upset clients
    • CFO: Tasked with ensuring the problem is fixed
    • Project Owner: The point of contact assigned by the CFO
    • Accounting employees: Tasked with entering in information and currently unable to do so effectively in two systems
    • Customers: Being invoiced by the company (currently incorrect amounts)
  4. How will they be affected by completing this project?

    So now we have these stakeholders identified:
    • CEO: Will retain the clients
    • CFO: Will save the day if the project is a success
    • Project Owner: First big project with this company, so it is important for it to go smoothly
    • Accounting employees: Are unhappy with the current workflow. Additionally, this new one will make their jobs easier and produce more consistent data.
    • Customers: Will be happy to see the issue resolved and not look for another vendor

With a little digging, the whole project reveals itself to be much more complex than it originally sounded. But we also have a much clearer picture of who and what is involved with this project. The most important part of the work is building the correct foundation and mindset for each party involved, not the actual programming. Without identifying the stakeholders this would not be clear and the team would be completely focused on the technical aspects of the project instead of the stakeholders. Taking this step seriously is vitally important groundwork for the next step: Goal-Based Thinking


Step 2: Goal-Based Thinking


Imagine a story, like “Add test coverage to onboarding workflow”, is assigned to your coworker. The coworker reads the story without asking any questions but proclaims they can finish it within the sprint. Nearing the end of the sprint, the work is turned in for your review. Running the test suite reveals the test coverage to be 95% over the section of code they were assigned, which is obviously a great start.


Digging into the actual test code reveals the majority of tests contain assertions that, while touching lines of code, are not meaningful. The majority of what was added was frivolous, brittle, and unnecessary tests. Your colleague responds to these comments by saying that the story was to “increase the coverage” and that’s exactly what they did. While technically correct, this is clearly not in alignment with the goals of the stakeholders. One could argue that this is an issue with the story itself not indicating that the tests need to be meaningful, that is, the story was not fully specced out with all the details. But anyone who’s ever specced out a story before knows there’s no way to add every single detail to a story to cover all possible interpretations and requirements. Part of a developer’s job when they receive a story is to clarify the acceptance criteria so that they understand exactly what is expected.


Everyone has had the experience of describing what they want only to receive work that “technically satisfies” the requirements while completely missing the desired outcome. Goal-based thinking greatly improves the probability that the result is what we want. When a developer understands the goal behind the work they will have a much greater chance of turning in work that aligns with that goal.


To nail this point home, let's look at another profession where goal-based thinking is crucial: construction workers. A high-level goal for most construction projects is to ensure the safety of the people who will use that building. Nailing boards, screwing in screws, putting up walls, setting tiles are simply the implementation details of the overall goal. If they accomplish all of those implementation details perfectly, but in the end, they create an unsafe building, then they’ve still failed.


A developer’s job is not to turn in code but to solve a problem, usually a business problem or project problem. It is not to have a high degree of test coverage or to follow a specific pattern. Your job is to solve problems that achieve the goals of the stakeholders. Keeping this in mind is crucial to becoming successful.


Finding the Goals Behind Tasks


Figuring out the goal behind a particular task can be difficult if you’re not used to goal-based thinking. Let’s use the example above to illustrate how to find the goals and reasons behind tasks.


In a surface level reading of the story, the original task, “Add test coverage to onboarding workflow”, can be expanded to mean: “Increase test coverage in the project.” This a great first step because it reveals that the original task is a part of a larger goal for the whole project instead of one specific aspect. But we need to dig deeper and ask “why do we want to increase test coverage in the first place?” A naive answer is to make the CI and test coverage metrics look better or fit some arbitrary numeric metric that the programming community has decided is a good number to hit. But higher test coverage in itself is not useful to a project and certainly not to a stakeholder. Looking deeper into why developers and project managers push for higher test coverage reveals at least two, more meaningful goals:


  1. Ensure there are fewer bugs.
  2. Make the codebase easier to maintain.

Stopping at this level for a moment, it is already obvious why the work our coworker did above is completely useless for these two goals. His tests focused on increasing metrics of code coverage but not ensuring there are fewer bugs or making the codebase easier to maintain. In fact, his work gives a false sense of security against bugs by artificially increasing the test coverage metrics. Additionally, the team now has to maintain brittle, useless tests whenever new features are introduced.


But we can dig even deeper and ask: Why do the stakeholders want fewer bugs and a more maintainable codebase? Fewer bugs mean more time for developing new features, implementing new designs, etc, etc. An easier to maintain codebase makes developing new features easier and onboarding new developers. The reasons here are extensive and I won’t attempt a comprehensive review of all of them, but the benefits of increased coverage impact much of the overall product goals and outcomes.


Each task has a whole hierarchy of goals that will never be fully described in each ticket description. Several layers of goals need to be kept in mind for each story to ensure that the work you are doing aligns with each one. Failing to meet one goal of a project can be detrimental to the whole project. Take these series of articles about estimation as an example.


The goal of these articles is as follows:


  1. Align your output with the maximal value provided to the stakeholders
  2. Convince you that estimates are not evil but in fact an extremely useful tool
  3. Give you the tools to achieve maximum leverage at your work
  4. Make businesses more efficient and productive

If these series of articles about estimation achieved the first three goals but tanked efficiency and productivity for the businesses, this whole framework would be a failure. The business would eventually die despite you having leverage because the business would not be productive or efficient. Achieving all the goals of a task is important.


Step 3: Understand the Problem


After understanding the stakeholders and the goal behind the task, you need to fully and completely read the story. This might sound trite or trivial but many developers do not take this step as seriously as they should. Read all of the acceptance criteria, review all of the mockups, read all of the notes and comments, and read any discussions that led to the story thoroughly. During this time you need to make a note of anything that is unclear or confusing and bring this to light to your project manager or coworkers. If anything has been left out of the acceptance criteria this is the time to make that known.


Step 4: Verify Your Assumptions


Once you are confident that you understand the story completely, you need to verify any assumptions about what is expected. The stakeholder or PM will have specific expectations about what work should be done and what the completion of the story entails. It is important that your general assumptions of the story and scope of work are in alignment with what the stakeholder and PM expect. A good pattern to follow comes from Steven Covey’s book, The 7 Habits of Highly Effective People:


“Seek first to understand, then to be understood”


Most people approach new work with the intent to understand enough to get started. A better approach, Steven Covey would say, would be to understand the problem well enough to be able to explain it to your colleagues or stakeholders. Many teams have found success by requiring the developer to restate, in their own words, the problems they are trying to solve and the goals that will be achieved by completing the work


Step 5: Ensure It Is All There


The last step is to ensure that all parts of the work have been laid out and expressed fully. The goal of completing the work is to satisfy the stakeholders so that you can move onto another story or task. Making sure that the requirements for the completion of the story are fully specified is vital to stemming scope creep and making measurable progress towards the next milestone. Scope creep is a notorious problem in software development and a savvy developer will mitigate against this during this step.


When you do find that a story is simply not ready to work on, the best course of action is to create a “Spec Story”. A Spec Story’s acceptance criteria describes the missing pieces of the original story that still need to be defined. When a Spec Story is complete the original story will be ready to begin working on. The reason this is so effective is that it follows the exact same pattern as all the rest of the stories in this framework, you plan, budget, and estimate a story’s requirements. Planning and budgeting your spec stories earlier will ensure that the rest of your stories are still on track with the appropriate velocity.


Conclusion


Understanding a story fully and the goals behind that story are the first major steps in estimating effectively and increasing your value to employers. The next article will cover the philosophy and steps involved in providing the actual estimate itself.


---
At FullStack Labs, we pride ourselves on our ability to push the capabilities of cutting-edge frameworks like React. Interested in learning more about speeding up development time on your next project? Contact us.

Let’s Talk!

We’d love to learn more about your project. Contact us below for a free consultation with our CEO.
Projects start at $50,000.

FullStack Labs
This field is required
This field is required
Type of project
Reason for contact:
How did you hear about us? This field is required