Seven Unique Ways To Breath In New Life In Your Sprint Retrospectives

Sprint retrospectives are an important part of scrum methodology. For Agile practitioners, retrospectives hold a special significance, and offer an insight into the self-learning capabilities supported by scrum.

The primary objectives of a sprint retrospective meeting are:

·       Display the user stories to the stakeholders, which have been developed by the team during the daily sprints  

·       Have the user stories accepted by the investors as “shippable”

·       Discuss and review the entire sprint, and analyze it to find how the sprinting process can be improved upon

·       Find what lessons can be learnt from the sprint, and how the team can benefit from prior findings and experiences

 

One of the issues faced by the scrum team is the team members end up discussing the same issues and problems in most of the retrospective meetings. The team feels it is discussing the same topics again-and-again, and therefore it is redundant to hold retrospectives. In all aspects, the retrospectives seem to be going “stale” and the team might be just holding it because scrum advocates it. The learning and self correction process stops in such cases, and the retrospective loses its importance and functionality.

So how can you pump in new life in the retrospectives? A few pointers may help you improve your meetings.

1. Rotating the leadership

Instead of the scrum master facilitating the meeting, invite the team members to temporarily assume the role of a scrum master and conduct the meeting. Each member takes turns and facilitates the meeting in his or her own particular way and manner. The members can be asked to experiment with newer adaptations and ways of holding the meeting.

2. Changing the questions

The two standard questions most commonly asked during the meeting are:

1.     What did we do well this time?

2.     What can be possibly improved upon in the next sprint?

Instead, try asking the question:

·       What actually happened during the sprints, and how did it occur?

Individuals tend to look at things from their own perspectives, and at times, they might fail to comprehend the true situation if they are forced to look at issues from a different point of view which they are not familiar with. Asking questions which they find easy to answer can go a long way in making the retrospective more interesting and useful.

3. Varying the process

Each scrum team has its own method of conducting the meeting. While some teams prefer group discussions during the retrospectives, a few of the teams follow the traditional pattern of having one member demonstrate his or her work to the stakeholders. Whichever process you follow, try to change it by including variations into the meeting pattern. A recommended method is to use histograms indicating member satisfaction levels. The survey can be conducted anonymously and the findings presented to the entire team. Suggestions can be availed from the team members as to what new aspects ought to be incorporated to make the meeting interesting. 

4. Thinking about unique perspectives

Individuals and people who are not directly connected with the scrum project, but are still attached to the project somehow can be invited to attend the meeting. Vendors and system deployment personnel have different insights to offer since they are directly connected with the market and have a “working knowledge” about consumer psychology and requirements. Their participation can help the scrum team to avail a broader perspective regarding how the development of user stories should be ideally carried out.

5. Changing the focus

Every team has a certain focal point, which it concentrates upon while developing the project. Switching the focus can also prompt the team to come up with new ideas about how the scrum process can be improved upon. If the team is concentrating too much upon the engineering practices, the focus could be changed to collaborative working and solving technical issues by sharing out the problems.Read more on http://blog.quickscrum.com/post/2014/04/09/Seven-Unique-Ways-To-Breath-In-New-Life-In-Your-Sprint-Retrospectives.aspx

         "Please visit http://www.quickscrum.com to Free download the Quickscrum tool" 

The Main Reasons Why Work Is Not “Done” In Scrum, And Why the Acceptance Criteria Is Not Met

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. 

1.    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”. 

2.    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.

3.    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.

4.    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.

5.    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.

        Read more on http://blog.quickscrum.com/post/2014/03/19/The-Main-Reasons-Why-Work-Is-Not-%E2%80%9CDone%E2%80%9D-In-Scrum-And-Why-The-Acceptance-Criteria-Is-Not-Met.aspx

                        "Please visit http://www.quickscrum.com to download the Quickscrum tool"