I know one of the foundation of Scrum is trust and transparency. The Scrum master and PO must trust the development team in deciding what work can be done in the upcoming Sprint and how they will do it. The team is Self-organizing and shouldn't be directed by others.
Now, I assume a common expectation from the stakeholders (or Product Owners acting as an representative) is to finish everything the development team committed to in a Sprint. The team realistically may not be able to complete all items but this expectation could lead to development teams under committing the work. They may try to select enough items that they don't get in trouble for being lazy but not so much that they risk not finishing it all. On the flip-side, the development maybe tempted to pad estimates to boost productivity.
If there is an under commitment, wouldn't it impact cost? For example: The value that could have been delivered in say 4 Sprints, might take 6 (2 additional Sprints). And if there is padding, it can show an inflated velocity (I think it would make more sense to consider the value delivered instead).
Has anyone experienced such issues with estimation in real life? And, how do you ensure the velocity is improved without using it as a measure to gauge development team's performance?
Would love to hear and learn from your experience & suggestions.
Thanks Sergio for your frank feedback. Appreciate it.
I agree it may not be ideal but I don't see why padding shouldn't be consider when it can have an impact on the ROI? If the estimates are padded and the team can give 'n' no. of reasons to justify it, the no. of iterations to deliver value can increase, resulting in cost increase.
I may be incorrect in my understanding.
Regarding padding, there was a very active thread:Padding: Is this really a "Professional Option" ?
IMO, instead of calling it as "padding" or "buffer", we can call it as "contingency". However, an estimate is only really an estimate and not final number, at least in a technical project. So we should be open to changes in estimations.
...
1 reply by Sergio Luis Conte
Aug 14, 2020 5:02 PM
Sergio Luis Conte
...
Padding is not the same than Buffer and not the same than Contingency. If we do not understand the difference our destiny is failure.
Thanks Sergio for your frank feedback. Appreciate it.
I agree it may not be ideal but I don't see why padding shouldn't be consider when it can have an impact on the ROI? If the estimates are padded and the team can give 'n' no. of reasons to justify it, the no. of iterations to deliver value can increase, resulting in cost increase.
I may be incorrect in my understanding.
Hi Mohit, estimates do not increase cost. Inefficiency, lack of motivation and laziness will cost you more but estimates hurt no-one - unless you are somehow misusing them or believing them to be something other than a forecast. I think that is Sergio's point. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Aug 14, 2020 3:51 PM
Replying to Maria Lekha Johnson
...
Regarding padding, there was a very active thread:Padding: Is this really a "Professional Option" ?
IMO, instead of calling it as "padding" or "buffer", we can call it as "contingency". However, an estimate is only really an estimate and not final number, at least in a technical project. So we should be open to changes in estimations.
Padding is not the same than Buffer and not the same than Contingency. If we do not understand the difference our destiny is failure. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Aug 14, 2020 2:10 PM
Replying to Mohit Joshi
...
Thanks Sergio for your frank feedback. Appreciate it.
I agree it may not be ideal but I don't see why padding shouldn't be consider when it can have an impact on the ROI? If the estimates are padded and the team can give 'n' no. of reasons to justify it, the no. of iterations to deliver value can increase, resulting in cost increase.
I may be incorrect in my understanding.
With all my due respect and with the aim to help, Mohit my recommendation, just in case you did not that, take a closer look to estimation theory. But at the end, if people like to use padding, go ahead just my recommendation is being aware about the impacts and risk this type of strategy will make into the whole initiative. Saving Changes...
Maybe I was unable to convey my question right.
Appreciate all your inputs. Thank you.
...
1 reply by Sergio Luis Conte
Aug 14, 2020 5:41 PM
Sergio Luis Conte
...
In my case, I fully understood your question and I know it is a common practice. I face the situation to change this behavior each time I am assigned to a program/project no matter the approach/method/process the company uses to create the solution.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Aug 14, 2020 5:17 PM
Replying to Mohit Joshi
...
Maybe I was unable to convey my question right.
Appreciate all your inputs. Thank you.
In my case, I fully understood your question and I know it is a common practice. I face the situation to change this behavior each time I am assigned to a program/project no matter the approach/method/process the company uses to create the solution. Saving Changes...
Andrew SoswaTechnology leader| Leading global financial institutionElk Grove Village, Il, United States
To put it bluntly, doing Agile methodology without entire team buy-in in Agile Manifesto and Principles is sometimes pointless as you discovered.
I am hopeful that your org understands tenets of trust, self-organization, commitment, teamwork, truthful estimation, etc are present at your firm. But are they Inspirational values (i.e. those that you want to live up to) or they are truly values by which your org lives every day?
Philosophically... if everyone is padding, and everyone knows that everyone is padding, shouldn't we make padded estimate our true estimate?
As a process, I disallow padding, buffer, contingency, etc. It's a bad practice with bad consequences. If one of my devs is padding, I break his user stories to more detailed level. Besides user stories, more than 20 hours of work will be padded. PO and SM should foresee that and discuss with the team in Retros that each user story should be between 2 and 20 hours (I do not advocate to estimate by time thou). Your burndown chart would help you identify the issues.
What I am hearing, on the other hand, is that there are no Retros or the Retros do not produce expected results, such as taking why we did not deliver in the last sprint and how we will work as a team, with the tool, and the product that we have to be better next time. If the motto is "the beatings will continue until morale improves" - we will start padding.
I think that velocity was mentioned but burndown was meant in some posts. If you want to chat about that, please create another post. Saving Changes...
