Climate Action App: Creating and Estimating the Product Backlog (Part 5)

05 August 2020 • 5 minutes

Written by Christine Chien

image for 'Climate Action App: Creating and Estimating the Product Backlog (Part 5)'

Next step is to write out our requirements and estimate the work involved in building the CAA app. This is article five in the climate action app series.

Read the previous article in the series

If you’re building a house, you wouldn’t start without a clear set of plans so that the builders know what is expected of them, and developing an application is no different. Documenting your application’s requirements is an important step in the scoping process. Once you have those requirements, your team will have a better understanding of what they need to do; you can complete an analysis of what tools (or extensions) could be used to assist with the building; and your team can get a rough estimation of how long it will take to build.

This article looks at how we did this for the Climate Action App, breaking down each of the stages to make it as understandable as possible.

Writing Requirements

When you are scoping out an application, at some point you are going to need to put pen to paper, or fingers to keyboard, and write down what your requirements are. Depending on how you prefer to work, you might start writing them from the beginning, or you may choose to wait until your solution is more established before documenting what is needed.

This is done by creating a Product Backlog - also known as a list of requirements. For more information on what a product backlog is and the details to include in it, take a look at the article What is a product backlog?

At Codebots, we recommend that you refrain from formalising your product backlog until after you have a (mostly) complete prototype, since your solution may change drastically as you scope and discover things about your problem. However, once you have a single focused prototype it is unlikely to change too much, meaning you won’t be wasting time constantly changing and updating what has been written.

For the Climate Action app, we used the prototype as the basis for the requirements which we wrote. We worked through each screen of the prototype, writing a requirement for each piece of functionality represented on the page. This is a fairly effective technique, as it means that you are unlikely to miss anything unless it is not user-facing. You can then follow up afterwards with any technical requirements or any extra pieces of functionality which aren’t in the prototype.

Identifying Extensions

Once you have your backlog ready, you can use it to get rough predictions of what kind of work will be needed to build your solution. At Codebots, we use this opportunity to identify which requirements can be covered by our bot extensions.

We have created an Extension Identification tool which helps you look at each requirement individually and assess which extensions would assist with the building. For each requirement, an extension may either fully or partially cover the work required. You can use the Extensions Available on Codebots list to help you understand how each of the extensions can be used.

As a result of the document, you can gain a rough idea of how much of your application can be built by the bots, broken down by whether it is fully or partially covered.

Take a look at a recording of our team filling it out:


The Results

When we followed the extension identification process, we were able to estimate that the codebots extensions would able to cover or assist with 80% of the planned development work. Of that 80%, 25% could be covered by extensions straight of the box with no customisation required.

Image: Climate Action App behaviour identification results.

The breakdown of the Climate Action App showed that CRUD would be the primary extension which would assist with building the app (to capture data), with some help from dashboards (to create graphs) and the bot-written backend (for app management).

Completing the extension identification also forces the team to start thinking about how they are going to be implementing things, which in turn makes it easier to estimate the amount of work required.

Estimating the Work

The only thing you can guarantee when estimating a project, is that it won’t be 100% accurate - otherwise it wouldn’t be an estimation :). We have written a series of articles on this topic, diving into why estimating is so hard, the different approaches you can take, and how we estimate here at Codebots, just as an example. There is even a qualification for it in the Codebots Academy.

For the Climate Action app, we followed our standard procedure of estimating: using our Product backlog, we consider the time required to build it, the different risks involved, and the different factors which could affect development (see allocation factor, trim the tail, and tech spiking).

The people involved in this process were Jack, our primary developer, and Tessa, who has technical experience and has been estimating Codebots projects. Together, they went through the following steps:

  1. Choose a requirement to focus on.
  2. Have a brief discussion to ensure they both understand it correctly
  3. Open the prototype and view the requirement
  4. Clarify and make notes on any assumptions made
  5. Discuss potential implementation options.
  6. Individually:

    1. Choose how long you think it would take to develop
    2. Allocate a risk score for how complex the requirement is
    3. Choose a rating for how unfamiliar the development team is with the technology
  7. The average score for that requirement is calculated, and the allocation factor is applied
  8. Once all of the requirements have been estimated, review them and present to the team


Following the Codebots process, we estimated that the Climate Action App would take approximately 3.1 weeks to build, assuming that a single developer was working on it full time.

Once our estimations are ready, we can plan our approach and begin development!

Christine Chien

Written by Christine Chien

Marketing Operations and Partnerships

Our very own Christine is a marketer by day, nerd by night. If she isn’t developing our marketing strategy, she is usually found by her 3D printer or at a local plant shop.