I'm both new to PM and to Agile. I work with a very competent and self motivated team of developers and I think one of the challenges we have is sometimes in estimating. By very virtue of it's name I recognise that an estimate is just that.
This isn't a common theme but any views on improving estimating for agile (story points) other than those outlined in the Agile manifesto. Ideally it would be great to recognise/reward developers for accuracy of estimation. Saving Changes...
If you translate story points to hours - obviously this is not Agile Scrum, you're falling into Scrumfall. I'll explain...
Estimating by story points makes sense for sustainable teams (when there is turn over, there is high range of estimation of same user story).
Teams estimate by effort because it is team activity where FIRST they refine the user story and SECOND they immediately story point it. Somehow everyone missed the first step.
If teams translate story point to hour, i.e. User Story 1 has esitmate of 10 hrs., then whose time estimate is it? Certainly not Bob's who can do US in 5 hrs, of Frank who can do it in 15 hrs. So wrong.
It is relative because it is not objective.
Someone missed the step how story points fit in calculating velocity and long term-planning, but I started another post on that "Strategic Long-Term Estimation in Agile Scrum"
@Kiran - slicing user stories into same chunks? I tried, still team members where coming up with diff estimates. It simply does not work in complex requirements estimation. It might work in row-homes construction.
Thank you for your explanation Andrew. However Management would always want time estimation so you must figure out a way to provide such estimates.
If you don't convert points to time then you must use the velocity to determine how much time would it take to complete the project or part of it. Then if the velocity drops management would get excited.
In waterfall projects there is not much stress to keep the velocity up as velocity does not exist. Some say than by using Agile/Scrum you can't hide and must be transparent but in reality is just more pressure and additional stress on the working team members. For the PO and especially for the SM is not that much stress as they are not the ones having to deliver the work. Saving Changes...
If you translate story points to hours - obviously this is not Agile Scrum, you're falling into Scrumfall. I'll explain...
Estimating by story points makes sense for sustainable teams (when there is turn over, there is high range of estimation of same user story).
Teams estimate by effort because it is team activity where FIRST they refine the user story and SECOND they immediately story point it. Somehow everyone missed the first step.
If teams translate story point to hour, i.e. User Story 1 has esitmate of 10 hrs., then whose time estimate is it? Certainly not Bob's who can do US in 5 hrs, of Frank who can do it in 15 hrs. So wrong.
It is relative because it is not objective.
Someone missed the step how story points fit in calculating velocity and long term-planning, but I started another post on that "Strategic Long-Term Estimation in Agile Scrum"
@Kiran - slicing user stories into same chunks? I tried, still team members where coming up with diff estimates. It simply does not work in complex requirements estimation. It might work in row-homes construction.
Andrew -
you miss my point with regards to mature teams not needing to size any more. If all stories are small enough, then why size anymore? The focus can then be on how many stories (all of roughly the same size/smallness) we can complete within a fixed amount of time.
Kiron
...
1 reply by Andrew Soswa
Feb 08, 2020 10:46 PM
Andrew Soswa
...
Sorry, Kiron, totally missed to keep check of this post.
In my opinion the estimation is not an exercise in applying a random effort point to whatever requirements.
It is not used for looking at how team burns down the work in the sprint.
The primary purpose is for a long term planning (both a single deliverable MVP and Release Planning).
1. PO prioritizes the users stories in the backlog to be Backlog Refined with a knowledge of how one user story depends on each other to complete.
2. This network of stories gives PO visibility to create a simple critical chain path.
3. Team estimates each user story by effort.
4. Team completes users stories in a sprint that totals certain velocity
5. The team in the meantime Backlog Refines user story by effort points
6. PO takes each user story and its effort, plugs them into a sprint up to team's velocity and voila - you have long-term planning.
That is of course, dependent on sprints of equal sizes, same team, same members within the team, no PO interference with estimation of user stories, no firefighting while regular sprint work is forgotten, etc. Things that no one really follows in hybrid Scrumbut methodologies and yet expects Agile results.
Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
Jan 18, 2020 8:24 AM
Replying to Adrian Carlogea
...
"3. Story points and velocity are for the team and the team only. They help the PO prioritize, helps the team think through the work, creates a point of conversation when points aren't aligned, and helps the team plan work at a sustainable pace. Defend this. The moment management reviews your story points, the points will become meaningless, because your team will have to start gaming the system (remember that points are relative). "
If you are a project sponsor or project director you must decide how much money to allocate to the project or to one of its phases. Obviously there is no accurate way of estimating the needed budget but still you must base your decision on some estimates no matter how accurate they are.
If the story points are only for the team and management should not be allowed to use them then how can the sponsor/director estimate the needed budget???
It is virtually impossible to stop management from using the story points. If you don't provide them the points, so that they can convert to days, then you must find an alternative way of estimating the time needed to complete the project (or one of its phases) so you can provide this information to them.
Some years ago I worked as a developer on a project that was using Scrum. The User Stories were all written from the beginning so the velocity was known from the beginning. If we were dropping bellow the set velocity we were considered a low performing team. That was a nightmare and I am sure many developers have such horrible experiences with working "Agile".
You can't stop management from using the Scrum estimates and metrics as they need them but when they do use them it can end up a nightmare for the workers especially for those that are doing the actual work.
If your management was monitoring team story points and the team lived in fear of lagging velocity, then your team was not working in a safe environment and I would bet money that the organization was not agile. You can't micromanage your teams and claim any high degree of agility. You don't get empowered teams, you get minions.
What you've described is common, though, and that's why I guard my teams' velocity closely. It's an internal metric for them to aid in planning and calculate estimates. As soon as managers turn it into a performance metric, it becomes meaningless. The team living in fear has only to inflate their story points to increase their velocity. Now your team has delayed the executioner, but your product owner cannot effectively estimate delivery. Management isn't assisting the product team in this scenario, they're destroying it.
Rather than share my team's velocity, the PO should use some of the common tools (like burn charts, for example) to set expectations. Yes, a competent stakeholder or customer can easily deduce average velocity from a burn chart, but that's a much different scenario than having an authoritarian manager beating down a team based on some nonsense iteration performance metric. An organization that insists on such a thing either doesn't understand the iterative and complex nature of the work they've undertaken, or else they're using buzzword terms like "agile" and "story" to disguise the authoritarian work culture they've established.
...
1 reply by Andrew Soswa
Feb 08, 2020 11:05 PM
Andrew Soswa
...
Wade, agree with you up to "Rather than..." You should guard influencing the velocity by PO or others, but it is velocity that is used by PO and others to long term plan. Velocity is truly meaningless to the team "hey this sprint we achieved 56 story.
points but last sprint 70" - what does it mean for the team? Not much. What it requires, is the Scrum Master understanding complexity of one sprint vs another and realizing where it leads into so-called "plateau of productivity" - which is en established velocity of the team over many sprints. This Plateau is an effort number that is used for long term planning by PO and others in management.
On the other hand, I would not give opportunity to PO to look at my burn down charts because they are very specific to how my team and I run as a team within a sprint. PO would destroy a team if he/she has chance to drive a team by burn down chart. It is Scrum Masters job to correct, give feedback, improve, refine burn down charts.
Agree with Scott. If estimation by effort gives you a headache - estimate by hours but you must understand what you lose by doing it. Since it is Agile anti-pattern, you will lose ability for the team estimation and random assignment to any team member with comparable skills. Why? Imagine a super-Dev guru estimating a user story by hours that will get assigned to a junior dev. I think that it paints a familiar picture to all.
Obviously, estimating by hours then would require one person to create a critical path of all user stories to complete certain MVP. It is doable. But is it Agile? Are you sure that Agile methodology is a good use for your product/service type? Maybe waterfall, or lean, is your better methodology.
Stay agnostic to a methodology - concentrate on the value of your end deliverable.
Saving Changes...
Felix JimenezBusiness Analytics Manager| AlconFribourg, Fribourg, Switzerland
Just remember to recognize and reward when actual performance is close to the estimates. We often only reward for coming under our estimates. That leads to padding.
Reward accuracy and also control on what has been done. I mean by this that if the work is done faster or slower to understand what has caused this change to introduce this factor next time we estimate. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Points are simply used as a mechanism for the team to understand how much work can be completed for a given sprint. Metrics will serve two purposes
1) to help the team understand from a data point perspective insights into their sprints efforts, which help to validate or invalidate previous assumptions, say on flow of work.
2) to validate assumptions on feature and epic size. From this, could show that X feature was delivered through N story points which spanned Y sprints. With that, you can begin to gauge how long to satisfying the vision statement (or project completion) based on number and size of features.
Too long? Revisit MVP for each feature. Still too long, revisit MVP for each epic. Saving Changes...
Scott TheusSenior Project Manager and Agilist| BWX TechnologiesEuclid, Oh, United States
Oct 28, 2016 6:46 PM
Replying to Faisal Patel
...
Interesting concept of rewarding someone for right sizing the estimation. I agree with the comments of estimation takes practice. We have devised and agreed upon a Train level assessment where 1 point = 10 hours of work; this helps translate the actual work and also in budgeting and financial calculations (different topic).
Estimation are done collectively as a team and the team should be rewarded as a whole. It surely helps in keeping the team motivate to continue to improve and correctly assess their work. Invariably, it rolls up into one of the roles of a Scrum Master to improve the team. So Kudos to you!
Hi Faisal,
It seems you are adding a level of complexity by assigning a value of hours to each story point; if your story points are translated into hours anyway why not just use hours for estimating?
I've found that using story points is helpful with getting the team to estimate in work effort, not in duration. If everyone knows that 1 point equals 10 hours the focus shifts back to how long something will take rather than how much work it is.
-Scott Saving Changes...
Andrew SoswaTechnology leader| Leading global financial institutionElk Grove Village, Il, United States
Jan 21, 2020 5:40 PM
Replying to Kiron Bondale
...
Andrew -
you miss my point with regards to mature teams not needing to size any more. If all stories are small enough, then why size anymore? The focus can then be on how many stories (all of roughly the same size/smallness) we can complete within a fixed amount of time.
Kiron
Sorry, Kiron, totally missed to keep check of this post.
In my opinion the estimation is not an exercise in applying a random effort point to whatever requirements.
It is not used for looking at how team burns down the work in the sprint.
The primary purpose is for a long term planning (both a single deliverable MVP and Release Planning).
1. PO prioritizes the users stories in the backlog to be Backlog Refined with a knowledge of how one user story depends on each other to complete.
2. This network of stories gives PO visibility to create a simple critical chain path.
3. Team estimates each user story by effort.
4. Team completes users stories in a sprint that totals certain velocity
5. The team in the meantime Backlog Refines user story by effort points
6. PO takes each user story and its effort, plugs them into a sprint up to team's velocity and voila - you have long-term planning.
That is of course, dependent on sprints of equal sizes, same team, same members within the team, no PO interference with estimation of user stories, no firefighting while regular sprint work is forgotten, etc. Things that no one really follows in hybrid Scrumbut methodologies and yet expects Agile results. Saving Changes...
Andrew SoswaTechnology leader| Leading global financial institutionElk Grove Village, Il, United States
Jan 22, 2020 10:35 AM
Replying to Wade Harshman
...
If your management was monitoring team story points and the team lived in fear of lagging velocity, then your team was not working in a safe environment and I would bet money that the organization was not agile. You can't micromanage your teams and claim any high degree of agility. You don't get empowered teams, you get minions.
What you've described is common, though, and that's why I guard my teams' velocity closely. It's an internal metric for them to aid in planning and calculate estimates. As soon as managers turn it into a performance metric, it becomes meaningless. The team living in fear has only to inflate their story points to increase their velocity. Now your team has delayed the executioner, but your product owner cannot effectively estimate delivery. Management isn't assisting the product team in this scenario, they're destroying it.
Rather than share my team's velocity, the PO should use some of the common tools (like burn charts, for example) to set expectations. Yes, a competent stakeholder or customer can easily deduce average velocity from a burn chart, but that's a much different scenario than having an authoritarian manager beating down a team based on some nonsense iteration performance metric. An organization that insists on such a thing either doesn't understand the iterative and complex nature of the work they've undertaken, or else they're using buzzword terms like "agile" and "story" to disguise the authoritarian work culture they've established.
Wade, agree with you up to "Rather than..." You should guard influencing the velocity by PO or others, but it is velocity that is used by PO and others to long term plan. Velocity is truly meaningless to the team "hey this sprint we achieved 56 story.
points but last sprint 70" - what does it mean for the team? Not much. What it requires, is the Scrum Master understanding complexity of one sprint vs another and realizing where it leads into so-called "plateau of productivity" - which is en established velocity of the team over many sprints. This Plateau is an effort number that is used for long term planning by PO and others in management.
On the other hand, I would not give opportunity to PO to look at my burn down charts because they are very specific to how my team and I run as a team within a sprint. PO would destroy a team if he/she has chance to drive a team by burn down chart. It is Scrum Masters job to correct, give feedback, improve, refine burn down charts.
Agree with Scott. If estimation by effort gives you a headache - estimate by hours but you must understand what you lose by doing it. Since it is Agile anti-pattern, you will lose ability for the team estimation and random assignment to any team member with comparable skills. Why? Imagine a super-Dev guru estimating a user story by hours that will get assigned to a junior dev. I think that it paints a familiar picture to all.
Obviously, estimating by hours then would require one person to create a critical path of all user stories to complete certain MVP. It is doable. But is it Agile? Are you sure that Agile methodology is a good use for your product/service type? Maybe waterfall, or lean, is your better methodology.
Stay agnostic to a methodology - concentrate on the value of your end deliverable. Saving Changes...
