Retrospectives, even though a valuable part of any sprint, are often disregarded and underestimated by scrum teams. Team members and the scrum masters feel that if there were no major issues during the sprint, there is really nothing to be discussed. This could not be further from the truth however and in fact goes against the constant innovation and improvement philosophy of agile. So what should you do in case your team is falling into the pattern? There are exactly three things propose to keep in mind.
- Remind the team why it is important
First and foremost, the team needs to understand the importance and value that a retrospective adds. While it is all clear when the project begins, teams often tend to devaluate retrospectives towards the middle of the project. Even though the major kinks within the team are worked out by then, there are still improvements to be made and things to be discussed. Think about it – the type of work your team is doing at each stage of the project is likely not the same and therefore does require different approach to maximize results.
Thus make sure to remind your team that as their process is changing, their approach will likely change as well. Make them understand the retrospective as a great opportunity to voice their issues, hear out others and reach a mutual understanding for going further as a unit.
When implementing scrum for the first time, you read all about the roles, meetings, user stories and more. However, when it comes to planning the first sprint, most of us feel lost and unsure in what exactly needs to be done.
The basic steps of a sprint are pretty straightforward – plan, execute and finish, with the help of various meetings in between. However, after starting to implement, a lot of questions and uncertainties seem to appear and at this point most of the teams tend to start looking for the best practices. Unfortunately there is no such thing, and it is each team’s specificity that determines how the sprint needs to be organized. In other words, the best practices can only be created by the team itself.
While the best practices do not exist, there are some guidelines that you can follow to make the process smoother. Here is our take on the most important ones.
The duration of the sprint. Deciding what the duration of the sprint is going to be is completely up to you. However, remember two things – at the end of the sprint you have to provide an incremental value to the end customer and the sprint should be a relatively short iteration when compared to the whole project (most of the sprints run between 7 and 30 days).
Planning is a foundation of all works. Especially it’s important for project’s implementation. Team must set the main aim and to plan actions step by step. As Antoine de Saint – Exupery said “A goal without a plan is just a wish.” That is why planning is compulsory if you want to achieve the final result. Scrum teams always optimize the estimation and execution of work. Team uses short periods of time known as sprints. The sprint helps you not only to find the right balance in work but also if team faces with some problems sprint allows to change the scope or direction of the project at any point. Scrum has four kinds of sprint meetings: planning meeting, daily meeting, review meeting and retrospective meeting. Teams who prefer kanban than scrum know well about meetings called kaizen.
Everyone might agree with the fact that Scrum is the most popular methodology in Agile development. Many organizations use Scrum due to its simplicity and flexibility. In Scrum, work is confined to a regular, iterative work cycle, known as a sprint. Most of the time one sprint lasts from one week to 4 weeks, but in some exceptional cases sprint might take up to two months. Each scrum team can face such challenge – decide upon sprint length.