To prevent a project from getting overwhelming, project managers break down their tasks into specified intervals called “sprints”. (Alistair Cockburn recommends one month, others will say these sprints can be as short as two weeks). You reach these “mini-goals” one at a time, and ultimately you reach the final destination.(Read more about the definition of these terms here, thanks to Method 123 for that information) Alistair Cockburn that we mentioned will be talked about in a later article on the blog so be sure to check that out for information on his perspective.
Organizing these sprints so that the time is most effectively spent results in a lot more than simply completing tasks. If done correctly, you can also analyze the team’s processes, customize the work being done, and re-structure where needed to ensure maximum effectiveness.
For this reason, PMs need what’s called a retrospective to happen every sprint. Every time you have the opportunity to look back at how things have gone, you discover an opportunity to improve the future. If there are some budget discrepancies, time management problems, or even just a few places that need to be tweaked but not really repaired, the retrospective is a great time to perform the routine maintenance that keeps your team running smoothly.
What a retrospective will look like:
Purpose:
The purpose of a retrospective is to establish what works, what doesn’t, and make changes to improve for the next sprint.
People who come:
Scrum Master, Scrum Team, optionally the Product Owner
Questions to Answer:
What works? What does not work? How do we want to improve?
Outcome:
List of action steps outlining how to improve, these steps get added to the Project Backlog.
You should allow for about 2 hour to complete the retrospective, but that 2 hours could save you countless more hours in repairs or problems that you are able to head off in one planning meeting.
