We focus on processes to effectively and efficiently develop digital products. One of our processes is using Agile Development, which includes using Agile Points to assign a common definition to the effort required to complete tasks. In this post we’ll focus on the modified Fibonacci Sequence – 0, 1, 2, 3, 5, 8, 13, 21, etc – as an exponential complexity scale (good discussion on why, other than the cool name). This definition of complexity should be shared by a whole team, from developers, product owners, executives, to anyone else who’d like to understand the nuances and complexities of developing digital products within this framework. The framework allows you and the organization to have visibility into timelines, complexity, budget, and staffing.
Why do we need this? Because humans are bad at estimating effort, especially when complexity increases. In software development, large features have hidden complexities which don’t become apparent until one is “in the weeds”. Every team is different. The purpose of using Agile Points is to agree on software project estimates in order to most effectively plan and execute product development (sprints, tasks, etc.).
Points & Meaning
0 – Very quick to deliver and no complexity. In minutes
- One should be able to deliver many 0’s in a day
- I know exactly what needs to be done, and it’s going to take me very little time
- Example: Change color in CSS, fix simple query
1 – Quick to deliver and minimal complexity. An hour
- One should be able to deliver a handful of 1’s in a day
- I know exactly what needs to be done, and it’s going to take me little time
- Example: add field to a form
2 – Quick to deliver and some complexity. Multiple hours
- One should be able to deliver one 2 comfortably in a day
- I mostly know what needs to be done, where improvements/changes need to be implemented, and it’s going to take me some time
- Example: Add parameter to form, validation, storage
3 – Moderate time to deliver, moderate complexity, possible unknowns
- On the order of about a day or more to deliver
- I have a good idea what needs to be done, and it’s going to take me a bit of time
- Example: Migrate somewhat complex static CSS into a CSS pre-processor
5 – Longer time to deliver, high complexity, likely unknowns
- On the order of about a week or more to deliver
- I know what needs to be done at a high level, but there is a good amount of work due to complexity/amount of development, and there are big unknowns we’ll discover as we get into the work.
- Example: Integrate with third-party API for pushing/pulling data, and link to user profiles in platform
8 – Long time to deliver, high complexity, critical unknowns
- On the order of a couple weeks+
- I understand the concept and the goals, but it will take a while to deliver due to amount of work, complexity, and unknowns
- If we have an 8, we should breaking them into smaller tasks/issues with smaller point values and minimize the complexity
- This might require a Spike to architect/remove uncertainty, or be created as an epic with more granular stories within it
- Example: Overhaul the layout/HTML/CSS/JS of a web application
13 – Long time to delivery, high complexity, many critical unknowns
- On the order of many weeks/month
- Similar to an 8; this should definitely be an epic, and requires discussions around how to accomplish
- Example: Migrate application from an outdated data store to new DB technology and ORM
21 – You’re doing this wrong. 😉
Final thoughts
As you can see, this is not clear cut and leaves much room for interpretation. Estimating software development is difficult, and there are many factors to consider, including complexity to develop given existing architecture, team availability, business priorities, unforeseen third party complexity, use of CD (Continuous Delivery)/automated testing, etc. What teams should strive to do is build a culture where there is a good grasp on the solution, and all agree on definitions for the level of effort required to deliver each piece of functionality, task, bug fix, etc.
There are many topics which are not covered in this post, such as discussing spikes, the purpose of sprints in CD environments, and much more. Many digital developers also utilize Waterfall Methodology in place of Agile Development. Waterfall Methodology is relegated to very specific projects where the luxury of quickly iterating and adapting is not available – think ‘building a plane’. The main takeaway of this post is to start implementing Agile Points in your projects; research, learn, iterate, and figure out what works best for your team(s) and organization(s).
Other resources
As always your thoughts and input are appreciated.