Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
Function Points, sometimes wrongly called Feature Points are the "traditionally" used to measure the functional size of a project and then to benchmark projects against organisations or against industry. What is your experience with FP in Agile? Do you know a better functional size measurement fro Agile projects? Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Yes, I am. I am using it as a correction factor from estimates made in Story Points and/or Use Case Points. You can find works in that field inside the CMU SEI. Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
Than you Sergio. I will have a look there, they have pretty good technical reports. I am using data from ISBSG, I am a big fan of Caper Jones.
You probably have a more mature SP/UCP. I am an independent consultant and I change the site at least once a year. So far I didn't find any organisation that is mature enough in the Story Points estimation. Best case the understanding of SP is Ron's original time obfuscation when SP are associated with hours, worst case the estimation is meaningless.
...
1 reply by Sergio Luis Conte
Oct 10, 2018 9:29 AM
Sergio Luis Conte
...
Is you ask me, I will said: avoid the Story Points estimation. But, my approach is: I am using what best fits for the organization where I am working on. In my actual organization, people that not belongs to IT or software find Story Points a useful tool. So, what I did was put clear what Story Points meant (in terms of inherent error and subjetivity) which demands something like "evangelize" from month to all the organization, put clear the process and put clear all what will face for using them. In my case, for a chance of the destiny, I had the opportunity to interact with people that "created" Story Points method from the genesis so I learned from them all the "headaches" Story Points create on people that will use it until, as you mention, you mature on that which demands at least three initiatives. On the other side, I complemented Story Point with Barry Bohem´s Cone of Uncertainty to put clear what does mean the estimation we got into any iteration. Other important thing is: User Stories are not requirements. User Stories are only "an invitation to talk about requirements". That will impact the estimation.
Story points do tend to be used much more frequently for numerical sizing of the work items on projects following adaptive lifecycles but mature teams who are good at splitting their work can also just use the number of projected work items in a backlog as a method of sizing.
I've seen very few teams with the maturity to associate value metrics such as business value or risk with specific work items...
Kiron Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Oct 10, 2018 5:31 AM
Replying to Stelian ROMAN
...
Than you Sergio. I will have a look there, they have pretty good technical reports. I am using data from ISBSG, I am a big fan of Caper Jones.
You probably have a more mature SP/UCP. I am an independent consultant and I change the site at least once a year. So far I didn't find any organisation that is mature enough in the Story Points estimation. Best case the understanding of SP is Ron's original time obfuscation when SP are associated with hours, worst case the estimation is meaningless.
Is you ask me, I will said: avoid the Story Points estimation. But, my approach is: I am using what best fits for the organization where I am working on. In my actual organization, people that not belongs to IT or software find Story Points a useful tool. So, what I did was put clear what Story Points meant (in terms of inherent error and subjetivity) which demands something like "evangelize" from month to all the organization, put clear the process and put clear all what will face for using them. In my case, for a chance of the destiny, I had the opportunity to interact with people that "created" Story Points method from the genesis so I learned from them all the "headaches" Story Points create on people that will use it until, as you mention, you mature on that which demands at least three initiatives. On the other side, I complemented Story Point with Barry Bohem´s Cone of Uncertainty to put clear what does mean the estimation we got into any iteration. Other important thing is: User Stories are not requirements. User Stories are only "an invitation to talk about requirements". That will impact the estimation. Saving Changes...
Stelian ROMANProject Manager| MicroSafetyCarlingford, New South Wales, Australia
@Sergio, I also try to avoid SP as much as I can, I recommend sizes. It's interesting that even Ron said that he is sorry for inventing SP :). I find them very good at the Scrum Team level as a tool to learn estimation and risk management.
I also observed happiness among Business users, maybe because they think that by being able to 'size' Users Stories they have some control/understanding on what the Dev Team does.
My main concern with SP is the easiness to be manipulated.
...
1 reply by Sergio Luis Conte
Oct 11, 2018 5:21 AM
Sergio Luis Conte
...
Agree. Because of that is I made all the actions needed to clarify all related to User Stories and I record and publish all that happends around it to all the involved stakehodlers with the aim to made the process as better as we can in terms of the objective we need to achieve.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Oct 10, 2018 4:38 PM
Replying to Stelian ROMAN
...
@Sergio, I also try to avoid SP as much as I can, I recommend sizes. It's interesting that even Ron said that he is sorry for inventing SP :). I find them very good at the Scrum Team level as a tool to learn estimation and risk management.
I also observed happiness among Business users, maybe because they think that by being able to 'size' Users Stories they have some control/understanding on what the Dev Team does.
My main concern with SP is the easiness to be manipulated.
Agree. Because of that is I made all the actions needed to clarify all related to User Stories and I record and publish all that happends around it to all the involved stakehodlers with the aim to made the process as better as we can in terms of the objective we need to achieve. Saving Changes...