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 behaviours) 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.
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.
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 behaviours.
We have created a Behaviour Identification tool which helps you look at each requirement individually and assess which behaviours would assist with the building. For each requirement, a behaviour may either fully or partially cover the work required. You can use the Behaviour Identification Guidelines to help you understand how each of the behaviours 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:
When we followed the behaviour identification process, we were able to estimate that the codebots behaviours would able to cover or assist with 80% of the planned development work. Of that 80%, 25% could be covered by behaviours straight of the box with no customisation required.
The breakdown of the Climate Action App showed that CRUD would be the primary behaviour 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 behaviour 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:
- Choose a requirement to focus on.
- Have a brief discussion to ensure they both understand it correctly
- Open the prototype and view the requirement
- Clarify and make notes on any assumptions made
- Discuss potential implementation options.
- Choose how long you think it would take to develop
- Allocate a risk score for how complex the requirement is
- Choose a rating for how unfamiliar the development team is with the technology
- The average score for that requirement is calculated, and the allocation factor is applied
- 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!
Last updated: 07 August 2020