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 are put onto the Product Backlog as PBIs by the Product Owner. The organization is probably not yet Scrumming the Scrum.

✥       ✥       ✥ 

PBIs that the team comes up with might have lower ROI and never make it into the Sprint as new higher ROI items are constantly pouring in from the other stakeholders. Team gets frustrated as their PBIs won’t ever make it into a Sprint. The developers can do much to increase their quality of work life, and therefore effectiveness, with increments to the product, their tools, or their environment. Yet these changes rarely make it to the board room kinds of discussions that usually guide the strategic market direction, and therefore the contents of the Product Backlog and the work that gets done. This might also lead to situation where redesign is neglected as Product Owner does not see any value in it.

PBIs elicited by the Development Team can be important from their perspective, but new items from other stakeholders prevent the team’s items from getting into a Sprint. Or the team might not be able to convince the Product Owner to include it in the next Sprint.

The Development Team will not be motivated if they do not have a say on what to work on. They want to work on items in which they have invested and of which feel ownership. [1] For example, Google and Atlassian let their employees to work on whatever they want on a regular basis.

Items that may be motivating for the Development Team may have smaller ROI 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 does not have any exposure to market opportunities, they are more able to propose ideas that are outside the normative range of business concern. So some potential valuable innovations may never get implemented or tried out, if the Product Owner sees more value only for items that are “safe.” Furthermore, sometimes ideas might be far outside the box and it is hard to see their value until they are actually implemented.


The Product Owner organizes a Team Sprint every 5th or 10th 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 Product Owner to the backlog, otherwise it is not Scrum and certain aspects of visibility are lost.

✥       ✥       ✥ 

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, it should not be postponed indefinitely.

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 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 new ideas are needed, or the team should be let loose and be creative one might consider hackathons or some other creativity event. The Team Sprint can be used 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 ROI and keeping the team motivated.

An example is 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 from: (license: Public domain).