Team Sprint

a.k.a. Hack Sprint

Let the Developers propose work every few Sprints.

... you have a Product Owner and Product Backlog. The Development Team is coming up with new ideas, features, or innovations that the Product Owner puts on the Product Backlog as Product Backlog Items (PBI). The organization is probably not yet Scrumming the Scrum.

✥       ✥       ✥ 

Developers come up with ideas for PBIs never never make it into the Sprint as new higher value items are constantly pouring in from the other stakeholders. The team gets frustrated as their PBIs won’t ever make it into a Sprint. The developers can do much within their own sphere to increase their quality of work life and of the product, with increments to the product, their tools, or their environment. Yet these changes rarely make it to the board room level discussions that usually guide the strategic development direction, so they never make it onto the Product Backlog and never influence the Development Team’s work. This might also lead to a situation where the team neglects redesign as the Product Owner sees no value in it.

PBIs elicited by the Development Team can be important from their own perspective, but new items from other stakeholders prevent the team’s items from getting into a Sprint. The team often cannot convince the Product Owner to include technical items in a Sprint because he or she may not understand technical debt, or the merits of good design.

It is demotivating to the Development Team if the have no say on what to work on. They want to work on items in which they have vested interests and of which they feel ownership ([1]). For example, Google and Atlassian let their employees work on ideas of their own initiative on a regular basis.

Items that may be motivating for the Development Team may have lower value than those that come from the business. Therefore, the Development Team cannot work solely on those PBIs they find interesting. However, in the long term, it is a good idea to work also on those items suggested by the Development Team.

It is refreshing to get to work on something else, so it might even prevent burnouts.

Because the Development Team has limited exposure to market opportunities, they are more able to propose ideas that are outside usual business concerns. So some potential valuable innovations may be left unexplored or unimplemented if the Product Owner sees value only for items that are “safe.” Furthermore, sometimes ideas might lie far outside the box and it is hard for anyone to see their value until the team actually implements them.

Therefore:

The Product Owner organizes a Team Sprint every fifth or tenth Sprint or as best suits the organization. In this Sprint, the Development Team can choose whatever PBIs they want to include in the Sprint.


The work items (PBIs) should still go through the Product Owner to the backlog, otherwise it is not Scrum, and transparency may suffer.

✥       ✥       ✥ 

The Development Team can choose items they want from the Product Backlog, to define their own Sprint Backlog and Sprint Goal, to shape their own Product Increment, without respect to the usual practice of honoring the Product Owner’s ordering. In this way, the Development Team members really get to do what they want and it will keep them motivated. If there is something more important coming up from the Product Backlog, then the Team Sprint can wait for a suitable moment. However, the team should not postpone it indefinitely, but agree on a concrete target date for the next one.

Having a Team Sprint helps reinforce the Development Team’s sense of being an Autonomous Team.

If the Product Owner does not invest time understanding the value of the PBIs that the team has proposed for the Product Backlog, this approach solves that problem as well. The Product Owner might order the Product Backlog according to the perceived low market value of the team’s proposals so they end near the bottom of the backlog. But if the Development Team occasionally or periodically gets to decide freely which items they will take into the Sprint, their own PBIs will also eventually get attention.

As the team gets to work once in a while on what they want, they are more motivated to work also on other PBIs. The idea is to tap into the team’s passion and enthusiasm. Avoid, at all costs, using this opportunity to retire technical debt or to “catch up.” There should be no “quality Sprints,” “refactoring Sprints,” or other Sprints to retire technical debt, as they dilute the discipline of Done to which a team should attend every Sprint. In the extreme case that the Sprint Goal is to retire past accumulated technical debt, the Product Owner should legitimize the effort with one or more PBIs.

The whole Sprint should be dedicated for the Team Sprint, so that there is enough time for the team to achieve some meaningful Sprint Goal. If the team needs new ideas to fill up a Team Sprint, one might consider hackathons or some other creativity event. The team can use the Team Sprint to come up with bug fixes, new features, or even for developing tools. The team incorporates these items in their work plan as usual in Sprint Planning.

The Product Owner should balance between optimizing external value and keeping the team motivated.

An example is one of Google’s most famous management philosophies called “Google Fridays.” Some products that came out of this activity are: Google News, Gmail, and even AdSense. Gabrielle Benefield relates a story about introducing this idea at Yahoo!

In 2003 I came up with the idea of Hack Sprints, as some teams were complaining that the pace was relentless with Scrum, and that they never had time to draw breath and just think. The idea was to have the entire team decide what they wanted to work on for that Sprint. It’s like the idea of using 20% of one’s time for undirected work (“Google Fridays”), but more focused. They did it about every 6th sprint as I recall.

The team members included the Product Owner & ScrumMaster. Everyone had equal sway and you had to lobby and get others to agree to work on things together and to prioritize the backlog for the upcoming Sprint. Designers often wanted to look at the clouds and think up ideas, dev’s to fix annoying bugs, but often people came up with great ideas and got the whole team on board to build them.

Not many teams tried this but for the ones that did they said it paid off in spades. The ideas were excellent and people felt motivated and that they weren’t just 'sprinting' with no end in sight.


[1] Daniel Pink. Drive: The amazing truth about what motivates us. New York: Riverhead Books, 2011.


Picture credits: U.S. Air Force photo by Lawrence Crespo, 130206-F-NK166-510, http://www.nellis.af.mil/News/Photos/igphoto/2000077303/ (Public domain).