Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
In my actual company we are using Agile from long time ago for software and non software initiatives. I was in charge to implement it in Latin America and the whole company. What method to use? The method that best fit for the team dynamic. Just to comment, the last one we implemented is T-Shirt and Story Points BUT if and only if the team is comfortable with that. We work with an architectural approach so the method is one component more that can be replaced inside our architecture as if you play with Legos. The same for other components.
...
1 reply by Aditi Bhalla
Oct 23, 2020 8:40 AM
Aditi Bhalla
...
Good to hear about your role in your company. Is it everyone from business analyst to development team was following Tshirt Sizes or BAs were using their own different estimation techniques . They must also be estimating before the work comes to development team.
Probably the method of estimation has more to do with the type of work and the team doing the estimating than whether the team are taking a specifically agile approach.
For software and data products, if estimates are essential then relative estimates (story points) tend to be more accurate and easier to manage that absolute estimates. My favoured method would be no estimates. Focus on collaboration, productivity and continuous delivery without the distraction of formal estimates. Saving Changes...
Aditi BhallaProduct owner| Human Health ProjectMadison, Wi, United States
In my company, as it was startup company, using estimation was a big deal. The team started with absolute , then slowly moved to T-Shirt. But still the estimation didn't come accurate due to less Product knowledge. It took about 6 months for the team to get into required estimate as now they were able to estimate relatively. Estimation is a challenge thats why everyone has moved from absolute to relative because relative is doable. Saving Changes...
Aditi BhallaProduct owner| Human Health ProjectMadison, Wi, United States
Oct 23, 2020 6:50 AM
Replying to Sergio Luis Conte
...
In my actual company we are using Agile from long time ago for software and non software initiatives. I was in charge to implement it in Latin America and the whole company. What method to use? The method that best fit for the team dynamic. Just to comment, the last one we implemented is T-Shirt and Story Points BUT if and only if the team is comfortable with that. We work with an architectural approach so the method is one component more that can be replaced inside our architecture as if you play with Legos. The same for other components.
Good to hear about your role in your company. Is it everyone from business analyst to development team was following Tshirt Sizes or BAs were using their own different estimation techniques . They must also be estimating before the work comes to development team.
...
1 reply by Sergio Luis Conte
Oct 23, 2020 10:48 AM
Sergio Luis Conte
...
As you mentioned, in my personal experience but mainly in my actual work place, is the new role we implemented: BRM. As you now is very close to BA (taking BA in the right definition, not the definition that somebody use close to a requirements taken). So, at the very begining when idea is created we use T-Shirt. But as I mentioned just in case the group is comfortable with that. Mainly because we use the same way of behave for every solution we need to create. Then, for example, if we have to make a modification to a line of production and engineers in charge use stattistics method for estimation no problem with that we take the basement estimations and we cascade it to estimate the other components of the solution . The estimation method is totally independent of the approach/life cycle/method you use to create the solution. In fact, instead of "method" the right word is "technique" in the case we are talking about.
My preference is to have the team estimate in t-shirt sizes, then I'll apply a number (fibonacci sequence) to use for story points and to help determine velocity. The team I'm working with uses hours. This works "okay" when developing new code, but is always optimistic when fixing defects. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Oct 23, 2020 8:40 AM
Replying to Aditi Bhalla
...
Good to hear about your role in your company. Is it everyone from business analyst to development team was following Tshirt Sizes or BAs were using their own different estimation techniques . They must also be estimating before the work comes to development team.
As you mentioned, in my personal experience but mainly in my actual work place, is the new role we implemented: BRM. As you now is very close to BA (taking BA in the right definition, not the definition that somebody use close to a requirements taken). So, at the very begining when idea is created we use T-Shirt. But as I mentioned just in case the group is comfortable with that. Mainly because we use the same way of behave for every solution we need to create. Then, for example, if we have to make a modification to a line of production and engineers in charge use stattistics method for estimation no problem with that we take the basement estimations and we cascade it to estimate the other components of the solution . The estimation method is totally independent of the approach/life cycle/method you use to create the solution. In fact, instead of "method" the right word is "technique" in the case we are talking about.
...
1 reply by Aditi Bhalla
Oct 23, 2020 4:27 PM
Aditi Bhalla
...
Thanks for sharing your experience
Saving Changes...
Aditi BhallaProduct owner| Human Health ProjectMadison, Wi, United States
Oct 23, 2020 10:48 AM
Replying to Sergio Luis Conte
...
As you mentioned, in my personal experience but mainly in my actual work place, is the new role we implemented: BRM. As you now is very close to BA (taking BA in the right definition, not the definition that somebody use close to a requirements taken). So, at the very begining when idea is created we use T-Shirt. But as I mentioned just in case the group is comfortable with that. Mainly because we use the same way of behave for every solution we need to create. Then, for example, if we have to make a modification to a line of production and engineers in charge use stattistics method for estimation no problem with that we take the basement estimations and we cascade it to estimate the other components of the solution . The estimation method is totally independent of the approach/life cycle/method you use to create the solution. In fact, instead of "method" the right word is "technique" in the case we are talking about.
Thanks for sharing your experience
...
1 reply by Sergio Luis Conte
Oct 23, 2020 4:53 PM
Sergio Luis Conte
...
You are welcome. I spend my extra time here to learn from people comments and posts so is my pleasure.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Oct 23, 2020 4:27 PM
Replying to Aditi Bhalla
...
Thanks for sharing your experience
You are welcome. I spend my extra time here to learn from people comments and posts so is my pleasure. Saving Changes...
We use story points (SP) from "modified fibonacci" because they are relative, abstract and addable -- T-shirt sizes miss being addable. 8 SP or bigger is usually a hint to try to split the estimated item further before really planning & doing it. 13 and above should not go into the next iteration without splitting. 20 is simply "whoo, big", and 40 like "whohoo, really big, too many unknowns".
To dig deeper, all estimation primarily is about "educated guessing" (well: Informed guessing grounded on solid rationale) and should not be taken as guarantee or base for contracting in any way (but all-too-often it is). The relationship between estimates and reality is a statistical one. If some person wants to nail down an estimate to a contracted promise, this person should be informed about the probability of the estimate being "at least as high as the real future effort": The higher the requested confidence level is, the higher the resulting "estimate" will be due to its probability distribution properties.
But ... this statistic estimation stuff is all laid down in PMBoK anyway since decades? The younger agile stuff is just about the practical value of relative abstract, yet addable estimate values chosen from a series of numbers which increase approximately by a certain ratio from number to number (and is also nearly about 2 decades old). Welcome to the books ;-) Saving Changes...
(My first repy only talked about which number set and units we use and why, but not how to get to the numbers.)
Usually we use discussion and planning poker, based on the "modified fibonacci" number set:
For every item to estimate we try to grab by discussion what it is about in the project context and what it will probably take to implement it until our "definition of done" will be fulfilled. This discussion should be accompanied by a person responsible and accountable for WHAT should be done NEXT (and why it adds value to the project).
Then we use "planning poker" based on "modified fibonacci" in a very simple way: After we all feel ready to give an estimate, we each simply show our numbers by hand (resp. fingers) to signal 1, 2, 3, 5 or even 8. Of course we could use a card deck or an app or other tools, but our hands and fingers are just fine for us to be used for this. However, often we do not show the same value. If the difference is big, we restart discussion to gain further insight about why we have so different numbers in mind and afterwards we have a further estimation round. If there is no big difference we usually use the biggest number shown.
However this works best for iteration planning, but not for a huge pile of items. In this case we also discuss what will be to implement, but not that deep. After high-level discussion we try to estimate at least the most items by some kind of "magic estimation", e. g. building separate piles of item cards having roughly the same estimated effort, and discussing in more detail the remaining items for which we cannot agree right away. (There should also be online tools for doing this collaboratively remote.) The remaining items should be just a few which in turn deserve deeper discussion. This saves time but does not sacrifice too much accuracy for now. Of course such estimates should be viewed as less reliable than estimates based on a deep-dive team discussion -- and these estimates are aging also and get inaccurate just by time passing by. Saving Changes...
Community Champion
