Completing All User Stories And Tasks In The Current Sprint
Sat 12 Sep 2015 00:12
One of the biggest problems faced by teams new to the Agile process is that they fail to complete some of the user stories at the end of the sprint. It is important to identify the root causes as to why this happens and try to improve upon Agile implementation so sustained product increments can be delivered to the client.
User stories, tasks, and the ongoing sprint
Many software development companies and organisations, the world over, now use Agile to develop their IT projects. Agile is become more and more popular by the day, and this is justifiably so, because there are several benefits of being Agile and adapting to changes occurring in the product design while the product is being developed. The delivery of shippable product increments is very important to the client, and if the daily sprints are properly carried out, it is possible to maintain a sustained velocity and deliver finished products within time.
A common problem experienced by less experienced Agile teams and organisations new to the Scrum process is some of the tasks often remain incomplete at the end of sprints. The development team fails to develop the entire list of user stories selected in the sprint backlog. This directly affects the sprint goal. This is not a good practice since Agile focuses primarily upon sustained delivery of product increments, and as the tasks aren't completed at the end of the sprint, proper product increments are not delivered to the client. Moreover, the business value attached with the project is also affected. If shippable product features are not developed in time, the product may even end up losing its hold in the market when the release is eventually launched.
So what should the development team do to "churn out" releasable user stories and deliver a certain business value to the client? What process should the team follow? Is anything new required to be done to improve the Agile process? Are the "inspect" and "adapt" principles followed by the team?
The development team should
- Be a cross-functional team and each member should possess diverse skills - testing, delivery, integration, coding, design, etc. - required to develop the project.
- Clearly understand the sprint goal and the definition of ?Done? before starting with the development.
- Clearly estimate user stories before committing them to the sprint backlog. The team should be aware about the current team velocity and use those metrics while estimating the stories during sprint planning sessions.
- Properly segregate user stories in the sprint backlog into easily developable tasks. The tasks should not be granular. User stories should be properly disintegrated into finely developable tasks containing basic functionality.
- Plan properly, and ensure that the team members take up the tasks based upon their levels of expertise and capabilities. For example, a senior developer should ideally take up complex tasks while a new one ought to develop simple ones which do not consume much time.
- Each team member should complete a task totally before moving on to the next one. Tasks should not be left ninety or ninety-five percent complete and another task taken up subsequently simply because a minor technical issue needs to be resolved for the first task. All issues should be successfully resolved and the developer should make sure that the definition of ?Done? is properly satisfied for that particular user story.
- Share ideas and collaborate. The team members should learn from each other and make efforts to develop better ways and techniques to improve upon their skill sets.
- Self-organise. Each team member understands his or her own responsibilities and remains accountable for his or her actions. Agile advocates self-management and self-organisation. These principles should not be misused.
Scrum Master takes an initiative
The role of a scrum master is very important in Agile frameworks like Scrum, and the success of a sprint depends a lot upon how the SM interacts with the team. Here is what a SM should ideally do:
- Ensure that the fundamental Agile principles are properly implemented and followed by the team.
- Always participate in the daily Scrum.
- Play a servant-leader role and try to facilitate the proceedings rather than manage them.
- Suggest, and not advise, how less experienced developers should correctly handle tasks, and how to resolve them.
- Motivate the team and remain available whenever the team faces a problem. The SM intervenes only when the team fails to resolve an issue.
Dealing with obstacles and stumbling blocks
If the team lacks an ability to identify potential sprint pitfalls, or if the team members fail to respond quickly when they face a particular technical issue, it could well affect the sprint goal and leave the sprint unfinished. It is important to foresee what kind of problems the team is likely to face when user stories are being committed in the sprint backlog, and the entire team, including the product owner, should have enough experience to predict how the sprint is likely to proceed based upon the stories currently selected for development.
The team should:
- Immediately raise an issue and address it when a team member detects a technical problem.
- Collaborate and try to resolve the issue with the help of other team members. When and how to do this is up to the team. Generally, sprinting time should only be utilised for developing the user stories. However, when issues have to be resolved on an immediate basis, the team should hold a brief meeting ? akin to a daily stand up ? to decide when and how to resolve the issue.
Do not overcommit user stories
Sprints can also remain incomplete when the team takes up too many stories than it is capable of handling. The product owner is solely responsible for designing the sprint goal. As per the norms, the PO tries to increase the team velocity, and to achieve this, he/she may press the team to take up more stories. However, it is up to the team to correctly estimate and decide how many stories it is capable of handling, and how many stories should be committed to in the sprint backlog. While the PO ?owns? the product backlog, the development team controls the sprint backlog. Hence, it has a right to accept and reject stories based upon the current team velocity.
In real life, there could be other issues and problems regarding user stories as to why they might remain incomplete at the end of sprints. A few common reasons are discussed here since the majority of Agile teams usually face them.