In the first part about agile estimation, we explained fundamental principles of the estimation. Now it is time to think how to implement them in real life.
Reference stories
For estimation, we will need to have ‘the catalog of references‘ so we can compare all new requirements fast & accurate enough. In our first post, we did that with the first few buildings and then compared all the others to those references.
Our catalog should not be specified based on technology – we will not have 1 simple database table, or 1 simple API, or 1 form, or 1 test case in it. The reference catalog must contain valuable functionality.
If a product is front end app, the functionality should include data storage, backend, validation, form, an update of manual, tests. Functionality must be working and usable for the client. Similar conditions can be specified even the product is Saas, or mobile application, etc.
Examples of reference stories:
- Small edit form with 5 fields
- Simple text-based filtering
- Import data with up to 10 fields
- Workflow with up to 5 simple steps.
How to deal with different types of requirements?
New agile teams are many times multi-discipline for the first time. Team members do not know what exactly does it mean to develop requirements. Very often you hear “I know nothing about development, I’m support guy!” In such case create reference catalog with different types of requirements, but distribute them with the same values.
Later, once some requirements are done, you will know how much time you spent on the implementation of requirements.
Based on the time spent now you can align the scale accordingly by comparison of the time aspect.
I suggest updating the scale after few sprints. It must be done based on already completed stories, not based on the estimation of time before such story is completed! And, don’t care a lot about velocity chart before such alignment.
ScrumDesk Start! helps team to define such scale much faster with help of Complexity chart.
Estimation groups
What we want to achieve by all these steps is to define groups into which new requirements can be slotted fast & accurate enough. Team members will just compare requirements to requirements in the group.
Typical mistakes
- The catalog is created not together as a team, but by roles.
- The catalog is based on time, not requirements complexity.
- The Catalog values are aligned based on estimated time, not spent time measured once a story is completed.
- Values are very precise. The goal should be to create groups of requirements.
- The catalog is not created by team members, but some PMO, project management or managerial roles “to align catalog”.
- The catalog is not “discovered”, but defined upfront.
- The catalog is not maintained over time. The values are in practice typically updated once per year.
