Základné a nadstavbové vzdelávacie programy pre tím.
Dlhodobá podpora tímov mentormi.
Spoznajte potenciál pre zlepšenia tímu.
Príprava a nastavenie tímu pre tvorbu komplexných produktov škálovaným Agile.
Ucelený a zmysluplný rozvoj tímu
Základné a nadstavbové vzdelávacie programy pre Scrum Mastrov.
Dlhodobé programy rozvoja schopností.
Identifikujte svoje potenciály pre ďalší profesionálny rozvoj.
Príprava Scrum Mastrov pre prácu v škálovanom Agile.
Základné a nadstavbové vzdelávacie programy pre Produktových vlastníkov.
Pripravte sa na prácu produktového vlastníka škálovaného portfólia produktov.
Vzdelávanie pripravujúce firmu pre zavedenie Agile.
Dlhodobé rozvojové programy pre zavedenie agilných praktík do firmy.
Hodnotenie agility firmy a identifikácia potenciálov pre ďalšie zlepšovanie.
Príprava firmy pre škálovanie agilných praktík.
Domov / Blog / Agile Estimation: Principles
An estimation is questioned in software development for many years. How to estimate accurately & fast? And, is an estimation even necessary? Well, the question for thousands of bucks. Because estimation might be expensive. Especially in the age of changes.
In our agile training, we used to ask trainees to visualize the amount of outcomes they are able to finish per day and visualize it by hand.
Of course, the indicated amount will be different per person. Even it is just a feeling of the outcome, what you often see as a reaction is an immediate comparison. The aim of the game is, to compare performance to yourself, not to colleagues.
The next questions are: „How big outcome have you been able to complete per day one year ago? What about the next year?“
What you would see are hands moving up and down. The most often reasons are:
Should you still ask teams to give you an estimate in time units? No. Small change influences the exact value. You can’t be more wrong than with hours, or man-days as estimation units!
Try to ask 10 people for their estimation. Very often you will get 10 different results. Which one is correct? Well, the best one is the estimation of the team member who is going to work on the requirement.
But who is going to be once a sprint is started? We do not know that at all as we want to have shared knowledge in the team.
So this is a time to do the estimation differently. It is the time to apply the wisdom of the crowds. You have to ask the team for one estimation value they agree upon.
Most of the team will estimate numbers that are pretty close. Few guys will estimate extreme values, either too small or too big. Statistics, however, tell us that the truth is in the middle. Gaussians is simply Gaussians.
The beauty is not hidden in the result. The beauty is in the discussion about different opinions. A lot of assumptions are discovered during such team estimation.
The team is inclined to understand the scope and final estimation together.
Customers are often interested in an estimation that they consider for „precise“ estimation. Due to the complexity of software, this is, however, very often not the feeling of the team. They provide a rough estimation. So if the team provides hours or man-days, the customer might have the wrong assumption.
We do not have time to provide a precise estimation of the time unit. It is too costly in case of later scope changes. We need to be fast with it, therefore we need to find something else.
An experience shows that people are better with the relative comparison. The brain uses it daily for quick decisions. Do you drive a car? Well, your brain doesn’t calculate physics formulas. It compares the relative position of your car and based on that you act. In most cases it works, in some cases, you will get lessons learned.
Let’s look at the buildings of Dubai city. We want to compare the height of the buildings relatively. The reference building we want to use for comparison will be the building marked with the number 1.
Let’s agree on principles for the estimation:
How many times is Building A higher compared to Building 1 in your opinion? Well, most of the answers in our training are 1, they are equal.
What about the building B? The answers are typically different – 0.5, 0.7, 0.4 times. Our opinions are different because the scale is too wide and too detailed. Therefore let’s fix that with the following Planning Poker scale (defined by Mike Cohn from Mountain Goat Software).
What about now? The most answers are now the same – ½. Now let’s compare other buildings to three already estimated buildings.
Hopefully, you realized how fast your estimation was now. You should compare buildings not just to the reference building, but to other buildings as well. This will result in groups of buildings of similar sizes. They will not be precise in centimeters, but that’s fine as we do not need that for the rough planning.
Details of user stories have evolved over time. In the beginning, they are maybe just the titles. Later, in release planning, the product owner should describe them in user story format. In the sprint planning, there should be all details as acceptance criteria.
In the release plan, user stories are being considered as candidates which might be later pulled out of the release. Due to that, it doesn’t make sense to estimate user stories with time units. In such a case, we’ll waste a lot of effort on the estimation, especially in case some user stories will not be implemented later due to changes in plans.
All of that is a reason for estimation with story points. Yes, those numbers are on the cards.
Time estimation should be provided at the latest moment (if even), not earlier than in sprint planning.
The constant changes are the reason for fast and accurate, not precise, estimation. The team should estimate the value together to support knowledge sharing, work distribution, and faster planning. Story point should be used for preplanning and release planning sessions while time (if even) for sprint planning sessions.
Part II: Agile Estimation: Real Life
Part III: Agile Estimation: Story points, Hours or #noestimate?
Kedy zaviesť Agile? V článku priblížime, ako sa rozhodnúť, v akých situáciách má zmysel zavádzať Agile. Článok...
Projektový manažment sa vzhľadom na zmenu fungovania firiem smerom k Agile mení a prispôsobuje. Pripravovať podrobné...
Co dát komu pod stromeček? Otázka, která mnoho z nás straší pomalu od října (či chcete-li od októbra). Máte mezi...
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