Background
Many a times in an Agile project we start with unknowns when the business requirements are created at the Product Backlog level. We go with the agreement between the scrum master and the product owner that enough details will be available for the development team before the start of the sprint or iteration to carry on with their development work during the sprint.
What happens when clarity is not available
Quite often I have seen that due to various reasons we do not get enough clarity on the product backlog items. This results in changes to the release plans at a high level or at a lower level to the sprint plans. I have faced issues in past where my team has taken a risk of committing to work on a task where 100% clarity is not available thinking that the information will reach the team during the sprint. But when the required inputs were not available that resulted in delay in completing the tasks. This has a direct impact on the velocity of the team.
When enough information in not available upfront it also means the development, the business analyst and test teams can’t agree on the definition of ‘Done’. This can lead to ambiguity as to what looks like Done. From development teams perspective a particular task can be done but if the test team is not able to test it due to lack of clarity then it becomes an issue.
At times the development team might not be able to provide high level estimates for the product owner during estimation and planning session. If that is the case, product owner might be unable to get a clear idea as to how much time it will take to deliver the piece of functionality. Also it will be difficult for the product owner and scrum master to slot the stories in respective sprints. It might also mean that the scrum team might end up developing a low priority story as compared to a high priority one. This can also lead to underutilization of resources.
Software project management and specially the estimation is not everyone's cup of tea. If there is day today involvement from the product owner with the scrum team, it might be easier for him or her to make a decision on whether to reprioritize a story or de-scope it. But if the product owner is not involved in regular meeting with the scrum team it becomes really difficult to convince him and get an agreement on changes to the schedule or features.
Conclusion
In my opinion, according to best Agile practices there should be constant involvement of product owner with the scrum team. Also the scrum team should have 100% clarity on the task that they are supposed to work on in a particular sprint or iteration before it starts. Without these two things it becomes a nightmare to manage the schedule and deliver the project within stipulated timelines. In an ideal scenario the product owner or the business analyst should work at least 2 sprint ahead of the development team. It should also be the responsibility of the scrum master to ensure that product owner is aware of the planned tasks in next 2 sprints. This should enable the product owner to do all the background work to clarify the doubts raised by development team during the estimation and planning meeting. On part of the scrum team, they should work only on stories which have enough clarity. Because the team is committed to deliver the stories during the sprint or iteration it becomes imperative that they have all the required inputs available before starting the sprint and committing to the amount of work.
Hey Buddy finaly something I can comment on :)
ReplyDeleteI absolutely agree with the above, it is very difficult to deliver any requirement when the expectations are not clear !
Very Nice post ! and good stuff for me to takeaway
ReplyDelete