This post is part of our Scrum-series, and we have arrived at the fifth and last activity in the Scrum-process (according to our stripped down definition of Scrum) — namely The Retrospect.

Purpose

The smartest people I know, rarely do anything without seeking various forms of feedback on the results. I believe this urge for feedback and evaluation to be a core reason for their journey on the highway of constant improvement. The Retrospect facilitates this journey of constant improvement for Scrum-teams.

How

The Retrospect is time-boxed to 3 hours. The team members in turn all answer the two simple questions

1. What went well during the last Sprint?
2. What could be improved in the next Sprint?

A list of all answers is constructed during the Retrospect by the Scrum Master (his role being that of a secretary), and the team itself will prioritize the list by importance. Remember that the more issues (even the more negative) that are brought to the table, the better. If the team can find nothing to improve, this is a certain sign of an unsuccessful Retrospect. As humans, we’ll always be imperfect, but the most obvious sign of imperfection is believing that everything is just as it should be. Ensuring that there is continuous improvement is more important than only evaluating how good we already are.

If there are several suggestions for improvement, I would recommend not addressing all issues immediately. Pick just a few to improve for the next sprint. The actionable ones (like “We need more stable test-environment”) are put into the Product Backlog for prioritization. Normally they’ll receive a high priority. The non-actionable ones have served their purpose once they have been mentioned and discussed (such as “Commit your source code daily”). Just having mentioned something is often enough to fuel the team members own thoughts and visions about how to improve themselves and the process. Don’t force yourselves to break everything down to concrete tasks.

Identifying and articulating what went well during the sprint is of course just as important. It is a motivational mechanism that let you see the effects of past improvements more clearly.

Be brave

It is perfectly normal human behavior to shield ourselves from feedback we assume not to be entirely positive, or that might even be negative and require more improvement from of us than our current capability allows. However, in order to improve we need to lower our defenses, and allow ourselves and our accomplishments to be evaluated. It’s vastly better having heard suggestions for improvements and doing nothing about it, than never having heard it at all. Be brave. Listen to it. In the end, you’ll benefit from it.

You’ll see that the more negative issues that are discussed and evaluated in The Retrospect, the more improvements there will be to commend in the next retrospect.

As with the first segment, the second segment is also time-boxed to 4 hours. During the first segment the team committed to items in the Product Backlog. The purpose of the second segment of Sprint Planning, is to create a tentative plan for the Sprint (which means to create a Sprint Backlog).

I will use the remainder of this post to elaborate on Sprint Planning, second segment, creating the Sprint Backlog. This makes things all the more interesting.

1) The Sprint Backlog is created anew for each month

Everybody likes a fresh start. Ideally the Sprint Backlog is all green-lights by now, and can be cleared out to provide space for the new plan. However, if it is not (i.e. we did not complete all tasks from the last sprint), the team will discuss why, and then toss them back into the Product Backlog. All unfinished tasks we planned a decade ago (the software engineering-equivalent of 30 days) needs to be re-evaluated according to the current state of the product backlog.

The smooth sensation of starting over, having a new chance to do even better, not having to deal with the complexity of juggling previous plans while developing new ones, is not to be underestimated. It’s all a part in the key effort of keeping things fresh, lean and up-to-date.

2) Planning is done based on up-to-date requirements

During the previous sprint and the first segment of sprint planning, the Product Backlog is modified and maintained by the Product Owner. This ensures that when the team commits to items to complete during the next sprint, their commitments are based on the latest available requirements for the product. The advantages of this are as important as they are obvious. Up-front, deterministic planning in software engineering has had little or no success. Allowing the product backlog to evolve to reflect the current set of requirements and challenges, provides a mechanism of continuous inspection and adaptation, ensuring that we’re on the a path to create the right software solving the right set of problems.

3) The Sprint Backlog is created by The Team itself

It’s a core principle of Scrum that The Team manages itself. The team is cross-functional and handles all phases of the development cycle (planning, design, coding, testing). This ensures high-bandwidth communication between each phase. No large design-documents etc. needed, all information stays within the team. The team will visit all phases during each sprint.

No-one is to tell the team how to develop the software. This is best figured out by The Team itself, and thus the team should be put together of people with different talents. Making the team responsible for their own planning, yields fast resolution of challenges that surfaces during the sprint and requires resolution. The Team will only have themselves to turn to, to reorganize and adapt to the new situation.

4) Only tasks that The Team agrees to commit to is added to the Sprint

This is implicit from #2 above, but is worth mentioning in explicit terms. Making The Team responsible for planning their own work, they should also decide what can be done, and what cannot be done during one sprint. While the Product Owner controls direction, ensuring business value is created, The Team must ensure that the speed is right, and how to best navigate to move in the desired direction as quickly as possible. No-one is better positioned to decide this than The Team itself.

Over-committing in a sprint due to external pressure or influence, is likely to leave the team deprived of the sensation of actually finishing the sprint successfully. Given the natural human tendency to attempt to reach goals that are set (and feel really bad if we don’t), it stands the risk of compromising overall quality. Developers might cut corners to get to “done”. This introduces problems into future sprints, and slows down the project significantly. (It is vastly more expensive to deal with problems later, than handling them properly right away)

5) Tasks are broken down into manageable pieces and given estimates (of maximum 16 hours)

This helps The Team elaborate and understand the details of what it is committing to.

The team will first calculate a velocity for the sprint. The velocity is calculated by summing up the estimated amount of hours each team member can work on the project for the next month. (I.E. Donald can commit to this project with a focus factor of 0.7, Minnie can commit with a focus factor of 0.8. Knowing that there is about 150 work-hours in a month, we’ll have 150*0.8 + 150*0.7 = 225 hours, which is the velocity) We should not put more tasks in that what the Sprint velocity leaves room for. This is a simple yet powerful mechanism for realistic and predictable planning of the sprint.

Breaking down tasks to this level of granularity ensures that day to day progress gets visible to each of the Team Members. By checking out, say, 3 to 10 tasks each week, a clear feedback-loop on the progress is established, enhancing the sensation for team members of getting things done.

The estimates also works as time-boxes, and will focus efforts and help developers avoid the strive for perfection.

6) A Goal for the Sprint is created

An implicit goal of any sprint is to produce an iteration of potentially shippable software, with a focus on getting to done on all items that were committed to. (Done meaning that it is planned, designed, implemented and tested, ready to launch).

An explicitly defined goal that focuses efforts toward a single end, is nevertheless of high importance. As mentioned, it is a natural human tendency to reach for goals, and as we feel terrible not reaching the goals we set, we feel equally great when reaching them. A common goal yields cooperation between team members. The Product Owner is important for stating the goal.

A goal can be as “silly” as to “bring uncontrollable happiness to the accounting department“, to “impress the CEO” or to “decrease support requests by 50%“. More timid goals, such as to “launch version 1.0001” is also better than nothing. Whatever you come up with as the sprint goal, it must be tangible, not too easy and not too hard to reach. It’s hard to set proper goals for each sprint, but a goal must be formed nevertheless. Forming good goals is an art in which you’ll get better at it in time.

7) Team members signs up for tasks

This is an imperative part of The Team’s self-organizing and self-management, and it clearly illustrates the powers of empowering workers in complex, intellectual work — such as software engineering.

This mechanism ensures that each member gets to sign up for a proper set of challenges. Not too big challenges (frustrating) and not too small (boring). Either of these are likely the result when tasks are delegated by dedicated managers that do not fully understand each member of the team’s abilities and interests.

Team Members are likely to opt-in to tasks that contains the proper amount of challenges, and that interest and excites them, and this stimulates learning and personal development. Personal development and  excitement is at the core of the long term vitality of The Team and its members, and thus ultimately the success of the projects.

8) Set a Sprint Review (Demo) date

Before ending the session The Team decides when and where to have the sprint review (demo) meeting. Also, the time and location for Daily Scrums are agreed.

Done

After 4 hours The Team stops adding tasks to the Sprint Backlog no matter what. Any unresolved items are left for planning during the sprint. The Sprint is already 4 hours underway, the clock is ticking and the team is empowered to do whatever needed in order to reach the goals of the Sprint.

They’re away, having a great time, creating real business value.