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: Story points, Hours or #noestimate?
How to choose the best estimation unit at an appropriate time. Should it be story points or hours? Or even #noestimates at all? In Agile meetups, we often hear very strong opinions about estimation units. From some perspectives, it even sounds like a religion.
Most people express the opinion that hours are dead. „We have story points in agile so let’s use them.“ But once you discuss how they apply story points you will find subgroups here.
The first group understands and applies story points in appropriate ceremonies and in an appropriate way.
The second group understands the story points concept, but it doesn’t apply them at an inappropriate time. And a lot of people use Story points, but for them they just mean man-days.
There are still people who prefer hours. There are different reasons for that. The business model, non-understanding of story points, resistance if the organization, not a big change involved.
More and more often we meet guys who do no estimation at all. But even this group is split into those who really do not do any estimation at all, and another group who do not estimate but count the number of finished cards.
So, who is right and who is wrong? Well, the answer is ‚agile‘ in many ways.
All opinions are correct and wrong at the same time. Because it depends on the business context, the product, the team, ceremony and maturity with Agile.
Be aware that all things we mention here might be false in your case! Talk about the pros and cons with your team and decide together. We do not say that story points can’t be used here or there.
What we do say is that in many cases it might be easier for the team to start the Agile introduction with hours as an estimation unit.
Hours might be the best in the following situations:
More important than final estimated value is the knowledge sharing within the team. To understand the basis of estimation!
The discussion in the estimation round is a great source of knowledge as estimated tasks are more detailed and easier to be understood by team members. Combine such estimation with breakage of the backlog items into subtasks.
The mistake is not to estimate tasks but calculate the estimation with a focus factor on the mind. A typical indication of this mistake is the question „How many hours our man-day is?“ or a sentence like „Well if our man-day is 6 hours and this is 10 hours task, then that means 1,6 MD.“
Focus factor is used for the Sprint capacity calculation, not for tasks estimation! If you need to spend 1 day on the task, then you will spend 1 day.
We found it very valuable to break down backlog items into tasks and estimate time with every new agile team. We do hours estimation in the Sprint planning sessions only. Not in pre-planning, release planning, or backlog grooming. And, based on the team’s maturity, we try to incorporate story points as soon as possible for the user story level. Story points are for backlog items, hours are for tasks.
Storypoints are the next development stage for your team so you can spend less time in the estimation and more of your life in what you like. In the development and product creation.
Once you discovered and understood the story points concept, you will want to use them all the time. The benefits are quite nice. The estimation is pretty fast while still accurate. If you know how to do that. Please follow our previous articles (part I, part II) where you can find what the story point is and how to create the catalog of references.
Story points are the best if:
In ScrumDesk we use Story points in pre-planning sessions so I, the product owner, know in advance how many user stories I need to prepare. The velocity (the sum of completed story points) is one indicator that I check. It helps me to focus on the topmost important things and prepare them thoroughly.
Story points are a great estimation tool for program increment (release) planning activities. The team doesn’t need to go to the subtasks level which saves a lot of time. We apply As late as a possible principle here.
There are more things you can estimate with story points:
While all of them might work (don’t forget, Agile is about the agreements of your team), Mike Cohn (an author of the story points concepts) suggests in his last blog to think about story points as written in the fourth bullet.
In some frameworks, like Scaled Agile Framework, the 1 story point equals 1 man-day. This is because of many teams involved in the complex product development and an alignment of the estimation scales. But that doesn’t mean that you should estimate man-days after the scales are aligned.
TIP: Never estimate time for your user stories!
Even though story points work very well, there is another possible level that you can achieve in faster and more accurate estimation. It is #noestimate.
Are you building up the business? Can you run it without the numbers? So why you should be positive about the no estimation? Even if you are positive, how?
Well, it is not so hard at all with these rules:
Now your ‚software factory‘ produces items of the roughly same size. Like automotive factories producing roughly the same cars. And what you need is to know your throughput – the number of finished items per sprint.
Your velocity is the count of items produced per sprint.
So does #noestimate mean #nonumbers? Hopefully, you got it.
I personally think there is no agile estimation technique you have to follow. Agile is about adoption so choose the estimation technique based on your goals, problems, and the current team’s maturity.
ScrumMasters should not forget to educate team members, product owners, management, and even the customer. Arrange Question Answers or Lean Coffee sessions to get through the biggest resistance and to find agreements.
I observed evolving Agile teams getting from hours to #noestimate in one year. If they were allowed by the management and if they were still able to provide business performance indicators based on their way of estimation.
So what is your next level? Why do you want to achieve it right now? What are you going to discuss with the team tomorrow?
Part I: Agile Estimation: Principles
Part II: Agile Estimation: Real life
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