It is a common misconception that if you follow Agile/Scrum then giving a (fixed) price quote for your clients is impossible or at least very hard due to the “fact” that Agile/Scrum more or less neglect project planning or at least do not care much about them.
The only promise of Agile/Scrum is “we’ll work as fast as we can and we will see how much you will pay at the end”.
Well, first of all, let me convince you about the foolishness of this theory very quickly.
If you read my article about what Agile and Scrum actually are it should be obvious to you at first glance that Agile is not against responsible planning, not against fixed price.
Reading the principles of Agile it becomes quite clear for any careful reader that Agile has nothing to do with these topics directly.
Regarding Scrum… it is a framework without too many concrete things to say. So again, what does it have to do with fixed price quotes or careful and responsible planning? Nothing. You are right.
Let’s see what you need for a fixed price quote in an Agile Project
- Solid understanding of the framework you are working with: Agile Price Quote: Step 0 – Poor Vocabulary, Poor Conclusions, Poor Decisions
- Good understanding and record of your client’s business needs (scope, deadlines, etc): Agile Price Quote: Step 1 – Recording Business Needs
- Gathering estimations from your team: this article
- Calculating feature and project price: coming soon
- Agile contracting: coming soon
- Meeting your contract: coming soon
Actually these questions are to be answered no matter what kind of project you run, “classic” or Agile.
Let’s discuss some ideas about how we can handle these in Agile. Actually this is how we do things within Moresimp where they indeed work for us.
Do they not work for you? Let us know, we can share our experiences, and maybe we can help.
Gathering Estimations From Your Team
Well, well, our favorite topic since it is among the ones people are willing to die for proving that their approach is actually the right one (btw. what do you think about AMD and NVidia cards?).
We have our opinion as well, but it doesn’t matter much, what does matter actually is that whether your methods have served you well until now.
Are you satisfied with them? If your answer is yes, there you go, just go with them.
But you may want to read this just as a comparison, it may give you new ideas.
Before we start this discussion, we strongly recommend you watch this great material from Master Cohn on the topic.
After watching this video you should have a pretty clear picture on how and why Agile estimation and tracking (should) work.
However in practice we have seen different practices as well. We are fine with them as long as they help your project to be agile.
Let’s see a quick comparison of approaches we have met until now.
Mike’s Approach, Plus Some Thoughts from Us
As you could see in the video this approach separates project planning/tracking and tracking of progress within Sprints.
If there is only one thing you want to remember from this video then remember this: Story estimations and sub-task estimations have absolutely nothing to do with each other!
Project Planning and Tracking
For project planning purposes it suggests your team should estimate ALL the Stories in Story Points when the project starts. Practically Story Points are actually relative weights, a Story with 2 Story Points means that it takes twice the time for the team to finish this Story than to finish a Story with 1 Story Point. And means nothing more!
You can use Planning Poker to give these estimations and there are other techniques but we found them too childish for our own purposes while we see their benefits of course.
Your results should look something like this (we use Plangle for demonstration purposes).
Ok, and what about project tracking and predictions for the future?
If you take Agile principles seriously, the only measure of progress you can accept is that how many Stories are completed in a Sprint. If you add up the Story Points of these completed Stories you have your team’s velocity for that Sprint, easy enough isn’t it? You can use this velocity (and your own experiences/judgement) to predict the progress of your team for the future.
That means that during your Sprint you must focus on completing as many Stories as it is possible. Do not cheat! There are no half-complete Stories! Why? Have you met a developer who said “It’s 95% percent ready boss”, and he kept saying it for 3 days? That’s why.
|
What if I want to estimate my Stories in hours?
|
|---|
| Well, you can do that if you want, as long as you are aware of what you are doing.Let’s see an example.Using Story PointsStory 1 – 10 Story 2 – 15 Story 3 – 20 Story 4 – 15 Story 5 – 20 Story 6 – 10Let’s assume that in Sprint 1 your team completes the first 2 Stories, it means their velocity is 35. What do you infer from this? Probably something like “they will complete Story 3 in Sprint 2 but not Story 4”. And you’ll be probably right, however a single Sprint is far too few to treat the velocity stable enough to use for future predictions.Using HoursStory 1 – 10h Story 2 – 15h Story 3 – 20h Story 4 – 15h Story 5 – 20h Story 6 – 10h |
BUT usually your boss will say something like this
- hey, 2 guys completed 35 hours of work in a week? (let’s assume you have week long Sprints). They had 40 + 40 = 80 hours! They either lazy or cannot estimate! Anyway, just fire them!
- OR ok, so this project will be done in 90 hours? we have 2 guys? Fine! Let’s have a release party 2 weeks from now!
So as you can see, there is nothing wrong with Hours, as long as you do not treat them as Hours. But why would you hassle your mind with keep saying “ok, these are hours, but not that kind of hours, remember!” It makes no sense! If you do not like the name “Story Points”, just use “Ponies”, as we do! Makes no difference. These are just relative weights, nothing more! Keep that in mind!
Also, people are much better at relative estimation (if this is 2 then this is 4 or 5), it has been clinically tested.
|
But estimation in hours are more precise!
|
|---|
| No. Why do you think they are?You have X team members with Y experiences and Z knowledge about the project. Why do you think that X + Y + Z = Q1 if you estimate in Ponies and Q2 if you estimate in hours?They are seemingly more precise. But in Agile you must focus on data, facts and figures, and you should avoid tools and processes that promise more than the data behind them justifies. There is no magic! |
|
Which scale to use?
|
|---|
| There are many scales to use, Fibonacci (1, 2, 3, 5, 8, 13, 21, etc.) or the simplest 1-10 scale.The Fibonacci scale tries to factor-in the fact that the bigger a Story is, the more unreliable your team’s estimation is, while the 1-10 scale is just easier to get used to.You can even use the sum of your sub-task estimations as estimation for your Stories (see the concept below), it leads you to a larger scale (around 1-100+)We usually prefer the Fibonacci scale, because… it does not matter and it is more fun to use. |
|
Half-complete Stories
|
|---|
| As I mentioned, there is no such thing as a “half-complete Story”. If your Story meets the Definition of Done (DoD) then it is Done, otherwise Not-Done.Of course if during a Sprint your team realizes that a Story is too big and is able to split it into 2 Stories then you can close the one which meets the criteria and leave the other open.But NEVER count Stories into the velocity that have not met the DoD!Cheating makes no sense anyway, velocity is NOT for measuring the effectiveness of single Sprints, but is used for predicting how many Stories we can complete in the future. If you cheat you’ll just get false predictions, and who needs that? |
|
What if we cannot complete Stories?
|
|---|
Well, that’s bad, you should try harder.Seriously, for instance you can always
In order to be successful with Agile you must establish a team where every team member willingly helps the others on the tasks that hold the team back the most. You need automated tests to complete your Stories and your QA guy is on sick leave? Let’s have your frontend/backend guys to write those missing tests! Will they be slower? Of course! Does it matter? Well, depends. It’s up to your judgment. Do not forget that Agile is just a set of principles, and Scrum is just a framework, you still have to have team leader/PM skills to manage a team. Agile and Scrum won’t do your job on behalf of you. Thinking, managing and arranging things are your responsibility. |
Sprint progress tracking
We can use velocity to predict our progress for the future, but how can we track our progress within a Sprint?
Why do we even need it in the first place? Well, you do not need it. It is just motivating for the team to see how we progress compared to what we estimated.
To track our progress within a Sprint we split the Stories of the Sprint (usually in the Sprint planning meeting) to sub-tasks that covers the scope of the whole Stories. We usually use hours for sub-task estimations and in our time sheets.
Why? Because we would like to see if a task takes more time than we estimated. If it happens day-by-day then we probably won’t complete some Stories at the end of the Sprint or we have to change something to meet the Sprint goal (for instance add more resources to the project).
To build trust it is always a good idea to communicate our failure on meeting our own commitments to the Sprint goal as soon as possible.
Long story short, tracking your Sprint day-by-day gives you a hint about your progress and let you handle the situation accordingly.
|
How to estimate sub-tasks?
|
|---|
Considering an 8 hour long workday an average team member works around 6 hours (just think of cigarette/coffee breaks, reading facebook, etc.). It is inevitable no matter how much the management may complain about it. Your brain has to rest, and even in the breaks the discussions are going around some work related issues anyway.As long as you trust your team members, let them have their breaks. If you do not trust them, well, fire them. Seriously.BUT if you have to put 8 hours in your time-sheets (as we do) you must handle the remaining 2 hours somehow.We handle it this way.If you have to estimate a sub-task and you believe that you finish it during a work day, from the point you get in until you usually go home (try to imagine it!) then estimate it to 8 hours. If you think you could do 2 tasks like this within a day then give them 4 hours. And so on…Estimations we use for sub-tasks
You simply cannot give more precise, still, realistic estimations even if you are the most senior guy in your universe. |
If you are using JIRA once you set the “Original estimate” field of the sub-task to the estimation, you can use JIRA’s worklog feature or more sophisticated solutions such as the Tempo Timesheets plugin to record the hours spent on these sub-tasks.
JIRA Agile‘s burndown chart gives you a good overview on how your overall progress looks within the Sprint based on these sub-task estimations.
In Plangle you can give estimations to your sub-tasks pretty quickly.
|
How to split Story into sub-tasks?
|
|---|
| Well, we usually use a role-oriented approach creating “Backend task”, “Frontend task”, “QA task” for our Stories, but we know very well that it won’t meet the taste of many of the Project Managers.Books usually suggest you creating “task-oriented” sub-tasks like “Create a DB” or “Write automated test” since it is more “Agile” in a way that it does not prescribe who should do a task, encourages self organization, team work, etc. Well, it’s all true.Nevertheless we find it more useful to create role oriented tasks. It definitely has its pros and cons.Fortunately in Plangle we support both kinds of approach.The “Quick sub-task” concept is about the previously mentioned role-oriented sub-task creation (see the FE/BE columns? They stand for Frontend and Backend), while the “normal subtask” can be used for the task-oriented solution. |
Story estimation = Sum of Sub-Task Estimations
We have seen (and used) a modification of the approach above which says that you should use the sum of the sub-task estimation as your Stories’ estimation. Please note that it does not mean that you should estimate your Stories in hours! But what holds you back deriving your Story Points from the sum of the sub-task estimations?
It’s a tempting solution which works pretty fine as long as you always split ALL your Stories into sub-tasks and ALWAYS use the sum of their estimation as the estimation of your Stories.
Story 1 – 24 (story point)
- Subtask 11 – 8h
- Subtask 12 – 16h
Story 2 – 8 (story point)
- Subtask 21 – 2h
- Subtask 22 – 6h
It may look weird that you add up hours and get Story Points. But again, Story Points (and any other Story measures you choose) are just relative Story weights, nothing more. So does it hurt if you (consistently) derive those weights from the estimations of the sub-tasks? After all this you can get a finer grade Story Point, can’t you?
Anyway, if you like this approach we have good news, Plangle has a support for it.
You can copy sub-task estimations with only one click, or even make it automated.
Story estimation = Sum of Sub-Task Remaining Estimations
We have seen (but never tried) an approach where somebody wanted to make his Story estimations ALWAYS equal to the sum of the actual remaining estimations of their sub-tasks.
If you think about it a bit, it means that with this solution you believe that if you team says that “It’s 95% done” then it is true.
While we think it’s not an Agile approach, we are considering supporting this type of Story estimation as well within Plangle.
Leave a reply