Agile Estimation and Say-Do Ratio (By Gulistan)
Agile Estimation and Say-Do Ratio (By Gulistan)
In the Agile world, the delivery to the customer is among the foremost goals, and so, estimation is very critical for on-time delivery of a PSI (Potential Shippable Increment). For this reason, Scrum teams must be able to estimate properly. Teams should have a good ball park idea of what the work entails in terms of time and effort. There is a Say Do ratio that should be taken into account. As the phrase itself indicates, it is the ratio of the number of things said by a team or team member to the number of things that they have actually done. Ideally your say-do ratio is 1:1, meaning you have done everything that you said you would do. For the team, it means how much the team actually does versus how much it says it would do. Say-Do ratio can be at Team level- indicating how many Story points the team actually completed at the end of the Sprint compared to the total points that the team committed to do in the planning and it can also be at individual level.
This reminds me of a team I had that never completed the Story points they committed in the Sprint planning. What they did at the end of the Sprint was to just move the uncompleted 20-30 points to the next Sprint. When, as their new Scrum Master I questioned and inquired the reason for the shortfall which by then had become a normal phenomenon, the team had no qualms about it. Clearly, this team’s Say-Do ratio had a big gap and they were not even doing anything about it. They were quite comfortable with the practice. In the Sprint planning, I observed that they were having separate Stories for Design and Testing. At the end of the Sprint they would just complete Design Story and not the Testing Story. Consequently, Design Story would also not be considered complete and all those Story points would be moved to the next Sprint. How I overcame that problem is a discussion for another day. For today’s topic, I just want to cite this as an example of the Teams’ Say-Do ratio. Obviously, the reliability of the team and of the company itself was in jeopardy because of the low Say-do ratio of this team. So we got to be mindful of these things and ask us ‘what is the say-do ratio of this team’ or of ‘this individual team member’, during the estimation to arrive at a more realistic forecast. Someone having a high Say-do ration means, that person is reliable which constitutes a reliable team and eventually a reliable organization.
Depending on the client or project I encourage the teams to give a conservative or liberal estimate. If the client is fussy about things for even the littlest of the issues then I would encourage team not to estimate conservatively. Similarly, if the budget is too tight on a project or for a certain client, I ask the team to take that into consideration and give a conservative estimate.
When the company or organization, practicing agile development, has a product to develop, deliver and maintain, it has to be in increments. The Product is at the top, having a lot of great Features- some big and some small, some providing more value some less. To better manage the development and delivery in a smaller and frequent manner we need to break it down into MVP – Minimum Viable Features. We will then have MVP1, MVP2 …MVP3 or even more, to develop. MVP has ‘Features’ as the name suggests. A Feature is a substantial capability. At this stage we can start estimating. Features can be measured in T-shirt sizes.
A Feature is too big and therefore has a rough estimate of Small, Medium, Large, X-large, XX-Large called T-shirt sizing. It must be broken down further, based on how the User will use the Feature, into what we call User Stories which are essentially Requirements in Waterfall. A point to be noted here is that User Stories are described in business terms or non-technical words as opposed to technical terminology and they are estimated in Story Points.
It’s getting more interesting now. User Stories are estimated in Story points based on the famous Fibonacchi sequence of 1, 2,3,5,8, where the next number is an addition of the last two numbers. The gap between the points as the Story gets bigger accounts for the risk that might be involved when the Story is bigger or has more details. Furthermore, this estimate takes into account the collective estimate of the team – remember the Poker game of estimation. It’s not estimation by one individual or a manager so there are less or no chances of having a lopsided estimate.
In the next step we will get to the time factor, to the nitty-gritty, where the Individual team members break the User Story down to Tasks. Tasks need expertise of individual team members- Developers, QA, Designer etc. Only the person performing the task should know how much time it will take them to complete it and so they give their numbers in hours. Since Tasks require technical expertise they are described in technical terms as opposed to Story which is articulated in business like terms. Tasks are estimated in hours whereas Stories are estimated in Story points. This way we know more accurately how many hours will take a particular Story to complete.
Agile estimation puts us in a better spot to judge how big of a work is on hand and compared to the average Team velocity. We can then safely forecast the Functionality that we are able to deliver at the end of the iteration. This kind of approach keeps things in line and better estimates lead to better outcomes in regards to on-time delivery which not only indicates a high-performance team but is also the number one metrics for measuring success in modern day Software development.
By Gulistan
This reminds me of a team I had that never completed the Story points they committed in the Sprint planning. What they did at the end of the Sprint was to just move the uncompleted 20-30 points to the next Sprint. When, as their new Scrum Master I questioned and inquired the reason for the shortfall which by then had become a normal phenomenon, the team had no qualms about it. Clearly, this team’s Say-Do ratio had a big gap and they were not even doing anything about it. They were quite comfortable with the practice. In the Sprint planning, I observed that they were having separate Stories for Design and Testing. At the end of the Sprint they would just complete Design Story and not the Testing Story. Consequently, Design Story would also not be considered complete and all those Story points would be moved to the next Sprint. How I overcame that problem is a discussion for another day. For today’s topic, I just want to cite this as an example of the Teams’ Say-Do ratio. Obviously, the reliability of the team and of the company itself was in jeopardy because of the low Say-do ratio of this team. So we got to be mindful of these things and ask us ‘what is the say-do ratio of this team’ or of ‘this individual team member’, during the estimation to arrive at a more realistic forecast. Someone having a high Say-do ration means, that person is reliable which constitutes a reliable team and eventually a reliable organization.
Depending on the client or project I encourage the teams to give a conservative or liberal estimate. If the client is fussy about things for even the littlest of the issues then I would encourage team not to estimate conservatively. Similarly, if the budget is too tight on a project or for a certain client, I ask the team to take that into consideration and give a conservative estimate.
When the company or organization, practicing agile development, has a product to develop, deliver and maintain, it has to be in increments. The Product is at the top, having a lot of great Features- some big and some small, some providing more value some less. To better manage the development and delivery in a smaller and frequent manner we need to break it down into MVP – Minimum Viable Features. We will then have MVP1, MVP2 …MVP3 or even more, to develop. MVP has ‘Features’ as the name suggests. A Feature is a substantial capability. At this stage we can start estimating. Features can be measured in T-shirt sizes.
A Feature is too big and therefore has a rough estimate of Small, Medium, Large, X-large, XX-Large called T-shirt sizing. It must be broken down further, based on how the User will use the Feature, into what we call User Stories which are essentially Requirements in Waterfall. A point to be noted here is that User Stories are described in business terms or non-technical words as opposed to technical terminology and they are estimated in Story Points.
It’s getting more interesting now. User Stories are estimated in Story points based on the famous Fibonacchi sequence of 1, 2,3,5,8, where the next number is an addition of the last two numbers. The gap between the points as the Story gets bigger accounts for the risk that might be involved when the Story is bigger or has more details. Furthermore, this estimate takes into account the collective estimate of the team – remember the Poker game of estimation. It’s not estimation by one individual or a manager so there are less or no chances of having a lopsided estimate.
In the next step we will get to the time factor, to the nitty-gritty, where the Individual team members break the User Story down to Tasks. Tasks need expertise of individual team members- Developers, QA, Designer etc. Only the person performing the task should know how much time it will take them to complete it and so they give their numbers in hours. Since Tasks require technical expertise they are described in technical terms as opposed to Story which is articulated in business like terms. Tasks are estimated in hours whereas Stories are estimated in Story points. This way we know more accurately how many hours will take a particular Story to complete.
Agile estimation puts us in a better spot to judge how big of a work is on hand and compared to the average Team velocity. We can then safely forecast the Functionality that we are able to deliver at the end of the iteration. This kind of approach keeps things in line and better estimates lead to better outcomes in regards to on-time delivery which not only indicates a high-performance team but is also the number one metrics for measuring success in modern day Software development.
By Gulistan