Ron was quite disturbed since he got his music system. ‘It’s useless to me!’ He was yelling at salesman over the phone furiously. ‘How can you do that? What can I do with this system without the power cable and user manual? It’s of no value to me. This box is useless without accessories.” Salesman kept his calm and replied very humbly. “Sir, don’t worry. We know that. We will deliver the power cable after two weeks and user manual after three weeks.” Ron was shocked to hear that. So it was not a mistake but a planned delivery. He has no other way now but to wait till he gets his requirement completely done. One thing is clear; he will not go and buy any product from this company in future. Watch out for few words like ‘value’, ‘useless’, ‘completely done’. Is it about money or commitment or quality or requirement? No. The company failed to understand the ‘Value’ that the product offers to the customer. They understood the requirement, they delivered it on time but still it’s useless. It’s not completely done. The ‘Business Value delivered’ was ‘Zero’. I know this is a hypothetical case but just imagine what will happen if things like this happen with business IT!
Agile methodology focuses on ‘Business Value Delivered’. Instead of calculating and sizing the requirement in terms of time and money, agile makes you think in terms of business value that we are going to offer to the customer by delivering the product. Customer is more interested in ‘Value delivered’ than detailed project plans. In most of the software project management assignments we often try to plan and showcase the value invested in terms of time and money and nobody really thinks about the ‘business value’ delivered. One thing IT needs to understand that ‘Software projects are run for business and not for IT.’ WBS (Work Breakdown Structure), schedule, variances will speak about the effectiveness of the project management but not about business value. These things are also important but not the ‘only’ important things. Agile methodology helps us realize the business value offered and business value expected. Less the gap between two, more successful is the delivery. Remember, software delivery process is not going to change. “Analysis-Design-Development-testing-Support/maintenance” cycle will remain as it is till eternity. Agile makes it different in terms of packaging it together as a value which business finds useful. There is no point conducting agile ceremonies just for the sake of it. Most of the times managers tend to work traditional way under agile framework which may in fact hamper the ‘agility’ of the process.
I have listed 5 such phenomena which one should try and avoid while doing agile project management. I call it as 5 demons which threaten to be a part of your framework, structure and process, and you might not even realize that they are getting bigger and bigger to eat your system. They mark their presence in each part of the scrum life cycle from pre-plan, plan, execute, check and improve, and may produce unhealthy state of the deliverables. You don’t want them, right?
1. Break and Make
2. Unplanned Sprint Backlog
3. Zero Assessment
4. Partial Completion
5. Hours Calibration
Break and Make
As we all know, agile works on user stories and the ‘features’ which essentially are the requirements of the product. While drafting user stories one must ask this question. ‘Does this provide any value to customer?’ So adding a report to dashboard is definitely of some business value to customer, but preparing a test case document is not going to provide any kind of business value. It’s a part of tasks that a story may have. Most of the times, we end up breaking the user story into its tasks and making individual task as separate user story for the sprint. This will create a picture of very busy product backlog with very effective sprint velocity. But if we see closely, these are the tasks with some story points which are not even stories at all. It is like cutting an apple into 5 pieces and booking them as 5 apples which actually makes just one apple out of it. This will indicate the false sprint backlog and false burn-down of the product backlog. This will take your project away from agile. These tasks are important but these are tasks essentially and not the requirements. We should not assign story point for tasks but hours estimation should be done. Agile does not stops at stories. We need to have estimated timeline for each task for a story. Detailed FBS (Feature Breakdown Structure) should be done with the tasks required for each feature (story). Don’t get confused and confuse your product owner between stories and tasks.
Unplanned Sprint Backlog
When a sprint is started, the scrum master should be aware of its team capacity, its sprint velocity and the items in product backlog. Product backlog is the source of the stories for a particular sprint. Team should be able to pick the tasks up from the product backlog into its sprint backlog and plan those for the sprint. If the sprint velocity for a team is 75 story points/sprint (three weeks), then the sprint should be planned to complete user stories worth 75 story points for that sprint. If this is not planned, we cannot identify the effectiveness of the sprint in terms of points planned vs. delivered points. There can be some challenges like intermediate injections, impediments, re-planning, reprioritization etc. but this will really tell you how your team is getting ‘burnt’. These causes should be highlighted with proper RCA (Root Cause Analysis) and product owner should be made aware of it. This will help you plan future sprints. If planning is not done and stories are taken up in the sprint backlog as and when they are injected, this will not help to baseline the team velocity at any point of time and we will not be able to provide any sort of forecast. This will not help the project and team to be ‘agile’. Though agile does not focus on schedule variance and effort variance kind of metrics, team needs to make sure that ‘we deliver the committed as planned.’
Zero Assesment
Story points are not really related to the hours. When we estimate story points, we consider these three points: Uncertainty, Complexity and Efforts. All three are subject to change as we progress through sprint. It’s always advisable to spend some time to re-estimate the story points which is the basic step of assessment. This will help the team to give realistic estimations which will help stabilize the team velocity. If a story is estimated at 80 point because of lack of clarity, the re-planning/assessment should be done once the scope becomes certain and known to the team. If it’s continued as estimated, then we do not make justice to the business value of 80 point story. We produce false impression of value delivery. Assessments will help team to do the causal analysis of the variance by which team misses the sprint velocity or beats the sprint velocity. Each ‘miss’ or ‘beat’ calls for velocity revision. A false ‘beat’ can lead to future misses and any ‘miss’ will not help the team to be a continuously improving team. Assessment can be done at the time of retrospection and we can assess our initial estimations against the work teams done. This will always help in future sprints, making the team an agile and continuously improving team.
Partial Completion
Imagine the situation where you end up in a meeting without any evidence of the work that you did, hours that you spent and the output that you produced. I hate such type of situations. In agile if you don’t prepare you stories properly, you are going to end up facing either one of the above situation. A story should be a ‘unit requirement’ or a feature which cannot be broken further. Each story ideally should produce some outcome which possible could have the value worth its estimation (story point). If stories are not drafted properly, team starts working on it and it creates problem when we had to remove/change/postpone the requirement. Then a scrum master may end up closing partial points (e.g. 5 out 13 point story) and remove/change/postpone the requirement or close it without addressing the change or remove it keeping the work done unnoticed or create a story for the task completion and accommodate that in sprint backlog. This is going to produce false impression of the velocity and product owner/scrum master will never get to know the team’s true capacity and velocity. Such forced finishes will lead to velocity illusions from sprint to sprint.
Hours Calibration
Story point estimation of a user story is essentially a unit of measurement of the business value team delivers by implementing the story. Hours taken to complete this, is one of the factor which influences the business value, but it’s not the only one. Here we go totally wrong sometimes to map the story points to hours and start calibrating them on hours scale. If we want to map it, there is no point having story points altogether. Business requirements are different in nature and their fulfillment demands different set of skills, which are not same always. Teams who implement these requirements, are going to change and will not be same throughout. The people, who form the teams, have different skill levels and again, these are not same always. In such a changing environment, the hours estimation is not good enough to estimate the business value of a particular requirement and its implementation. If we take some real life examples, lifting a 25 kg box up to the height of 100 meters and cutting a wooden log are two totally different things. The time required for this depends upon the tools available and skill level and experience of the person who actually does this. Also the value delivered by the outcome stands significant in own its way. We just cannot compare these against time scale only. Hence the story estimation should not be done by comparing one requirement to other in terms of hours. Each story should be treated as separate story and this can be done effectively if we understand the business value that we deliver.
If you succeed to keep these demons at shore, I am sure your voyage will be agile enough to guide your passengers safely to the destination even in the environmental dynamics and disturbances!
Agile methodology focuses on ‘Business Value Delivered’. Instead of calculating and sizing the requirement in terms of time and money, agile makes you think in terms of business value that we are going to offer to the customer by delivering the product. Customer is more interested in ‘Value delivered’ than detailed project plans. In most of the software project management assignments we often try to plan and showcase the value invested in terms of time and money and nobody really thinks about the ‘business value’ delivered. One thing IT needs to understand that ‘Software projects are run for business and not for IT.’ WBS (Work Breakdown Structure), schedule, variances will speak about the effectiveness of the project management but not about business value. These things are also important but not the ‘only’ important things. Agile methodology helps us realize the business value offered and business value expected. Less the gap between two, more successful is the delivery. Remember, software delivery process is not going to change. “Analysis-Design-Development-testing-Support/maintenance” cycle will remain as it is till eternity. Agile makes it different in terms of packaging it together as a value which business finds useful. There is no point conducting agile ceremonies just for the sake of it. Most of the times managers tend to work traditional way under agile framework which may in fact hamper the ‘agility’ of the process.
I have listed 5 such phenomena which one should try and avoid while doing agile project management. I call it as 5 demons which threaten to be a part of your framework, structure and process, and you might not even realize that they are getting bigger and bigger to eat your system. They mark their presence in each part of the scrum life cycle from pre-plan, plan, execute, check and improve, and may produce unhealthy state of the deliverables. You don’t want them, right?
1. Break and Make
2. Unplanned Sprint Backlog
3. Zero Assessment
4. Partial Completion
5. Hours Calibration
Break and Make
As we all know, agile works on user stories and the ‘features’ which essentially are the requirements of the product. While drafting user stories one must ask this question. ‘Does this provide any value to customer?’ So adding a report to dashboard is definitely of some business value to customer, but preparing a test case document is not going to provide any kind of business value. It’s a part of tasks that a story may have. Most of the times, we end up breaking the user story into its tasks and making individual task as separate user story for the sprint. This will create a picture of very busy product backlog with very effective sprint velocity. But if we see closely, these are the tasks with some story points which are not even stories at all. It is like cutting an apple into 5 pieces and booking them as 5 apples which actually makes just one apple out of it. This will indicate the false sprint backlog and false burn-down of the product backlog. This will take your project away from agile. These tasks are important but these are tasks essentially and not the requirements. We should not assign story point for tasks but hours estimation should be done. Agile does not stops at stories. We need to have estimated timeline for each task for a story. Detailed FBS (Feature Breakdown Structure) should be done with the tasks required for each feature (story). Don’t get confused and confuse your product owner between stories and tasks.
Unplanned Sprint Backlog
When a sprint is started, the scrum master should be aware of its team capacity, its sprint velocity and the items in product backlog. Product backlog is the source of the stories for a particular sprint. Team should be able to pick the tasks up from the product backlog into its sprint backlog and plan those for the sprint. If the sprint velocity for a team is 75 story points/sprint (three weeks), then the sprint should be planned to complete user stories worth 75 story points for that sprint. If this is not planned, we cannot identify the effectiveness of the sprint in terms of points planned vs. delivered points. There can be some challenges like intermediate injections, impediments, re-planning, reprioritization etc. but this will really tell you how your team is getting ‘burnt’. These causes should be highlighted with proper RCA (Root Cause Analysis) and product owner should be made aware of it. This will help you plan future sprints. If planning is not done and stories are taken up in the sprint backlog as and when they are injected, this will not help to baseline the team velocity at any point of time and we will not be able to provide any sort of forecast. This will not help the project and team to be ‘agile’. Though agile does not focus on schedule variance and effort variance kind of metrics, team needs to make sure that ‘we deliver the committed as planned.’
Zero Assesment
Story points are not really related to the hours. When we estimate story points, we consider these three points: Uncertainty, Complexity and Efforts. All three are subject to change as we progress through sprint. It’s always advisable to spend some time to re-estimate the story points which is the basic step of assessment. This will help the team to give realistic estimations which will help stabilize the team velocity. If a story is estimated at 80 point because of lack of clarity, the re-planning/assessment should be done once the scope becomes certain and known to the team. If it’s continued as estimated, then we do not make justice to the business value of 80 point story. We produce false impression of value delivery. Assessments will help team to do the causal analysis of the variance by which team misses the sprint velocity or beats the sprint velocity. Each ‘miss’ or ‘beat’ calls for velocity revision. A false ‘beat’ can lead to future misses and any ‘miss’ will not help the team to be a continuously improving team. Assessment can be done at the time of retrospection and we can assess our initial estimations against the work teams done. This will always help in future sprints, making the team an agile and continuously improving team.
Partial Completion
Imagine the situation where you end up in a meeting without any evidence of the work that you did, hours that you spent and the output that you produced. I hate such type of situations. In agile if you don’t prepare you stories properly, you are going to end up facing either one of the above situation. A story should be a ‘unit requirement’ or a feature which cannot be broken further. Each story ideally should produce some outcome which possible could have the value worth its estimation (story point). If stories are not drafted properly, team starts working on it and it creates problem when we had to remove/change/postpone the requirement. Then a scrum master may end up closing partial points (e.g. 5 out 13 point story) and remove/change/postpone the requirement or close it without addressing the change or remove it keeping the work done unnoticed or create a story for the task completion and accommodate that in sprint backlog. This is going to produce false impression of the velocity and product owner/scrum master will never get to know the team’s true capacity and velocity. Such forced finishes will lead to velocity illusions from sprint to sprint.
Hours Calibration
Story point estimation of a user story is essentially a unit of measurement of the business value team delivers by implementing the story. Hours taken to complete this, is one of the factor which influences the business value, but it’s not the only one. Here we go totally wrong sometimes to map the story points to hours and start calibrating them on hours scale. If we want to map it, there is no point having story points altogether. Business requirements are different in nature and their fulfillment demands different set of skills, which are not same always. Teams who implement these requirements, are going to change and will not be same throughout. The people, who form the teams, have different skill levels and again, these are not same always. In such a changing environment, the hours estimation is not good enough to estimate the business value of a particular requirement and its implementation. If we take some real life examples, lifting a 25 kg box up to the height of 100 meters and cutting a wooden log are two totally different things. The time required for this depends upon the tools available and skill level and experience of the person who actually does this. Also the value delivered by the outcome stands significant in own its way. We just cannot compare these against time scale only. Hence the story estimation should not be done by comparing one requirement to other in terms of hours. Each story should be treated as separate story and this can be done effectively if we understand the business value that we deliver.
If you succeed to keep these demons at shore, I am sure your voyage will be agile enough to guide your passengers safely to the destination even in the environmental dynamics and disturbances!
Interesting insight. Nice read Aditya! Keep posting!
ReplyDelete