Perhaps the most important aspect of scrum methodology is the concept of “Done” or meeting the acceptance criteria while developing the tasks. The product owner, who represents the interests of the stakeholders, approves and certifies the acceptance criteria defined in individual user stories, or the product backlog items. It is very much important for the user stories to be accepted as “Done” because in scrum an item can only be considered as “shippable” and “complete” when its “Done” criteria is met. The terminology used to describe “Done” is synonymous with the acceptance criteria in scrum methodology. The words describe the same thing.
There are times when the acceptance criterion is not met, and the user stories are not considered as complete. This can be the worst possible scenario as far as conducting the daily sprint is concerned, since the basic objective of the sprint cycle is to meet the acceptance criteria and deliver a shippable product at the end of the iteration. Unaccepted and unfinished user stories reflect unsuccessful sprints and improper implementation of scrum.
It is worth knowing about some scenarios, which can result in a condition when the “Done” criterion is not fulfilled in scrum.
Lack of a good cross -functional team
By “cross functional” we mean a team, or a group of individuals having different areas of specializations, who work in unison to achieve a common objective or a cause. In scrum, if the product is technically complex, or if the functionality associated with the product is varied and extensive, it is essential to have a cross functional team. When individuals with different areas of specializations work together to develop a solution, it becomes very easy to carry out the development activity, since the technical requirements are catered to by developers who have required levels of expertise and can provide clear and concise solutions for a given task or a problem. Queries are resolved in a more successful manner, and in the least amount of time.
During the sprint, when or if a team member faces a particular problem, it is possible for other cross-functional team members to contribute their knowledge and skills, and provide a proper solution for the problem in hand. This makes the development work easy, fast, precise, and effective. It is very important, and recommended, for scrum teams to be cross-functional.
Non cross-functional team members may find it exceedingly difficult to find quick solutions when problems arise during the sprint activity. The primary reason why this happens is because they lack the required experience, or do not possess sufficient skill sets to offer effective solutions, which can solve the problem currently impeding further product development. The levels of expertise typically required may include designing, business analysis, development, database designing, testing, and other similar skills. It is essential for the developer to be proficient and very good in his or her work. Failing to have such technically sound team members in the sprint may result in substandard or defective developmental activity. Tasks which are not technically perfect, or which have bugs in them may not be accepted as “Done”.
Unclear or undefined acceptance criteria in the user stories and tasks
It becomes very hard and almost impossible for the development team to successfully complete the tasks included in the sprint backlog if the meaning of “Done” is not properly explained in the user story, of if the story simply fails to include the acceptance criteria required for its development. Typically, in such cases the team starts working blindly, and often pursues a vision of what the actual “Done” should ideally include in the user story. Rather than the product owner explaining the meaning of “Done”, the team assumes what the “Done” criteria is and starts developing the task based upon their assumptions.
This can prove to be a dangerous habit as far as the project is concerned since the entire team starts pursuing unclear and even undefined objectives which have no relevance whatsoever as far as the project is concerned. The result is a lot of “wastage” suffered by the stakeholders and the management in terms of unproductive working hours and human resources.
Using outdated or obsolete technologies for development purposes
Technology keeps on changing continuously. For the team members, it is essential that they remain in touch with the latest development techniques and trends. As it quite the norm, existing technology tends to “phase out” over time, and is replaced by emergent technologies, which are more powerful, dynamic, and effective.
Using older technologies may lead to incomplete development, simply because phased out technologies do not have the potential to offer the functionality needed to develop a competitive product. Moreover, the team may find it very hard, or impossible, to meet the acceptance criteria, and not be able to develop the task. At times, the definition of “Done” may not be satisfied by using out dated technologies. Using old engineering practices can lead to undue wastage of development time, and even lead to the development of sub standard products. It is very important to use upcoming and newly emerging technologies to deliver quality products.
An overworked development team
The stakeholders and the management are mainly concerned with marketing the product once its development is completed. Their objective is to launch the product as soon as possible, and benefit from the amount they have invested in the project. They often compel the scrum team to take up more work, or even complete the project well before the decided completion date.
This can make the development team to cut corners while completing their sprint tasks. Since the team is forced to work against time, it is going to affect the development and quality of the finished tasks. As enough time is not available to check and verify the acceptance criteria, the team may simply decide to carry out the development and submit their tasks in the sprint review meeting without verifying the acceptance or “Done” criteria. The team fails to perform properly because it is compelled to “deliver more” and it simply lacks the time to check the acceptance criterion.
Lack of collaboration and integration activity
The main essence of scrum is collaboration. Team members should work in a joint manner to achieve common objectives. Scrum methodology also advocates team members to co-operate and help each other when problems arise and solutions are required. Moreover, collaboration is essential when the team is undertaking the sprint. Collaborated efforts lead to a well-organized team and improved productivity.
When the team members start working individually and stop collaborating, it leads to a situation where in the tasks are not properly linked up, or integrated in a proper manner, to be effective. Generally, during the sprint, the segregated user stories are developed in the form of tasks, and the tasks have to later integrated to fulfill the acceptance criteria. If the team members are working individually, the tasks cannot be integrated or linked up as specified in the acceptance criteria. The definition of “Done” is therefore not fulfilled.
Unfocused sprint planning meetings and product owners uncertain in their thoughts
Scrum is very clear about what needs to be done, in what manner, and when. There is a clear-cut indication about the project flow and the development cycle as to how they are supposed to function, and what they are set to deliver. During the sprint planning meeting, the product owner transfers a set of user stories or product backlog items into the sprint backlog from the product backlog for development purposes. Once the first half of the meeting is over, the team members segregate the user stories into individual tasks during the second half of the sprint meeting, and distribute the tasks amongst themselves. Subsequently, the sprint is carried out to develop shippable items. This is the normal process flow, and scrum can be successfully implemented if this flow is followed in a preplanned manner.
If the product owner starts developing second thought regarding the user stories included in the sprint backlog for development purposes, it can lead to a lot of confusion and disarray, especially if the sprint backlog items are “changed“, or some of the items in the backlog are transferred back to the product backlog and replaced by new ones. The team loses it focus since some of the tasks which have already been completed before cannot be linked up with other ones because other tasks have not been developed yet. The team may have to re-plan the development schedule and may not be so clear about the acceptance criteria associated with the new items included in the backlog. The programmers may fail to fulfill the “Done” criteria because they have not been able to plan for it in an organized manner before the inception of the sprint.
Lack of proper planning and mutual disagreement regarding “Done”
One of the perquisites in scrum is to have proper planning amongst the team members. Each individual has a specific role to play while scrum is being implemented in the project. In scrum, everything depends upon planning and group efforts. The sprint planning meeting, sprint review meeting, the sprint retrospective meeting, and the product backlog refinement activity are also carried out as per plans. If scrum activities are not properly planned, it can lead to a disarray of related events, and the development activity may suffer as a result thereof.
One of the perquisites in scrum is to have proper planning amongst the team members. Each individual has a specific role to play while scrum is being implemented in the project. In scrum, everything depends upon planning and group efforts. The sprint planning meeting, sprint review meeting, the sprint retrospective meeting, and the product backlog refinement activity are also carried out as per plans. If scrum activities are not properly planned, it can lead to a disarray of related events, and the development activity may suffer as a result thereof.
If the product owner and the team fail to reach to a proper agreement regarding the acceptance criteria mentioned in the user stories, the upcoming sprint may be seriously affected in terms of submitting the deliverables. Since there is no mutual acceptance of the definition of “Done” within the scrum team, the development team may not have a clear objective as to how, and in what manner, the tasks should be developed during the sprint. In fact, the team may not have an objective in the first place when it undertakes the sprint since the meaning of “Done” is not defined mutually or accepted by all involved.
Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!
