Domov / Blog / Agile Estimation: Real life
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.
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:
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.
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.
Ako správne písať požiadavky v agile? Typické chyby pri písaní user story. Product ownership zmysluplne....
Veľa firiem sa rozhodlo implementovať SAFe preto, aby vyriešili svoje problémy, ale tak ako pre ostatné agilné frameworky,...
Veľmi dobre si aj z osobnej skúsenosti uvedomujeme, že pri množstve práce a tlaku okolností, je často náročné dokázať...
Nenechajte si ujsť výber toho najlepšieho z Agile, s čím sa stretli naši mentori.
Nielen zo sveta produktov, vývoja, tipov a trikov, ale občas aj humoru. Posielame pravidelne, raz za občas :) #QualityOverQuantity