User stories and the product owner
During the sprint planning event, the product owner proposes new product features for development purposes while the development team negotiates with him/her to accept the user stories. It is an important scrum event since it forms the base of all development activities in Agile and Scrum, and gives birth to the product developmental cycles – the sprints – that commence almost immediately after the event. The product owner supports the product vision, and one of his duties is to ensure that stories having high business values are developed in the sprint just about to begin. POs tend to push development teams so stories do not remain incomplete at the end of sprints. There is nothing more “damaging” than an incomplete sprint in Scrum – it adds on to development backlog and reduces the team velocity.
Why user stories remain incomplete
In practice, the development team performs under a certain degree of pressure since the tasks have taken up by the team members have to be completed within time. Developers generally prefer to take up easier tasks for development first. The idea is to complete as many numbers of development tasks as possible within the shortest possible time so the team velocity can be increased. However, in the process, developers also tend to follow a practice not recommended from the development point of view – taking up new tasks for development and leaving the current task unfinished because it is consuming more time, is difficult to complete, or there is some problem associated with its development. This is not a good development, but people still follow it at times to show they are “productive”. Productivity is generally thought about in terms of how much work has been completed by a particular team member and marking tasks as “Completed” is a great way to indicate that you are productive. However, it should not be done at the cost of leaving tasks unfinished. It can lead to even more stressful conditions at the far end of the sprint when team members suddenly realize there are incomplete tasks pending and very little time available to develop them.
What should be done?
So how is it possible to avoid these type of practices in Scrum where work is not completed in a proper manner, or at a proper time? Should the Scrum process be changed to monitor and check these type of activities? Should the Scrum Master closely monitor the implementation and do something he or she is not supposed to do – micromanage the development process? Actually, the solution can be very simple. The team should be made to understand and follow when to “start” with something, and when to “stop” doing it. It is not difficult to do, and what is more important, it helps to deliver business value to the client – and that too in time. In fact, if the team understand when to “start” with something, it becomes easy to determine when to “stop” doing something that is currently underway since you cannot work on two or more tasks simultaneously.
Keep it simple and straightforward
The condition is simply – complete the current task and subsequently start with a new one. If the task is difficult to complete by the developer, the team should hold a brief meeting to discuss the issue and make a mental note to include the particular issue in the retrospective sessions held after the sprint has been completed. The point should also be reported in the daily stand upheld the next day. The inspect and adapt principles should be followed to support the self-correction process. Once a solution is found for the issue, it should be i
mplemented immediately, and the team should learn from the experience.
It is important to know about factors which can possibly lead to situations where a team member might be compelled to leave a task undone:
Calculating the team velocity
It is important to know how productive the team is, and what the team can accomplish with regards to development within a sprint. Many times, the Scrum team does not put in enough efforts, or take the velocity parameter seriously. The PO is tempted to include as many stories as possible in the sprint to reduce the total number of iterations. It is essential to meet the release date, and if more stories can be developed in a sprint, the project can be completed well within time. In the haste, the development team takes up more workload that it can possibly handle. This is a scenario typical of teams new to Scrum.
If the current team velocity is properly identified and known, a correct number of product backlog items can be included in the sprint backlog during the sprint planning event. The PO should honor the current team velocity and suggest a more realistic number of stories that the team is capable of developing in the sprint. The team should not be pushed into accepting more stories than it can possibly handle. While working under stressful conditions, the developers may not have enough time to carry out unit tests which could lead to regression later on.
Learning from the retrospective
What is so unique about Scrum is that it supports the inspect and adapt principles which are characteristic of all Agile frameworks. Agile allocates a special event known as the “sprint retrospective” to look back and reflect upon the Scrum process – To identify potential pitfalls and find out why the team faced problematic situations, why they occurred, and how they could have been avoided. The retrospective offers a learning experience so the team can self-correct itself. Teams should take the retrospective sessions seriously and hold brainstorming sessions to set up proper call-to-actions and work out effective self-correcting processes. Any problem faced by the team during the sprint can be discussed openly during the sessions and workflow can be altered to ensure that the same situation does not occur again.
Implementing call-to-actions effectively
Once possible pitfalls and root causes of problems have been identified, discussed, and solutions worked out, proper call-to-action should be defined and implemented so the team does not face the same issue again. Very often teams simply fail to design properly follow- up plans, or if they are worked out, the team fails to implement them properly. This renders the self-correction process ineffective. Moreover, the inspect and adapt principles remain unfulfilled. It is important to react to inputs during the retrospectives. The inputs should result in actionable outputs in the form of call-to-action. The team should implement what has been decided to do at the end of the meeting.
Correctly estimating user stories
The product owner carries out the estimation activity when the product backlog items are defined in the backlog. Generally, the PO estimates the user stories and is often aided by the Scrum Master and the development team during the estimation process. While the PO owns the product backlog, the development team, in fact, owns the sprint backlog, and at the time of sprint planning meeting, the team negotiates with the PO how many stories it can complete in the scheduled sprint. Both the PO and the team work out the total number of stories to be developed based on how the stories have been estimated. A sprint may include a few stories and fewer tasks if the complexity of the stories is large, and more time is required to develop them.
A common problem faced by teams in the early instances of Scrum implementation i.e. when teams are new to the Scrum process is they often fail to estimate stories correctly. Scrum advocates relative estimation rather than estimating absolute values in terms of how complex the development could be. This can prove to be confusing to the team in the early stages since people are more used to absolute estimations. The entire team should understand the estimation process and correctly estimate the stories before accepting them for development purposes.