Development Team

The Development Team are expected to be a team of effective self organizing professionals who deliver “done” work or the potentially releasable Increment at the end of each Sprint. The Development Team is also expected to be cross-functional with all of the necessary specialised skills and focus areas to independently transform Product Backlog items into a potentially releasable product Increment.

Responsible For

• Determining how to deliver, and completing the work towards a potentially releasable Increment that is deemed to be “done” at the end of each Sprint
• Conducting the Daily Scrum
• Defining the Definition of Done

Sprint Planning Topic One (Why)

• Works as part of the Scrum Team to form the Sprint Goal

Sprint Planning Topic Two (What)

• Collaborates as part of the Scrum Team
• Determines and forecasts the work to be developed during the Sprint with respect to their capacity and past performance

Sprint Planning Topic II (How)

• Determines how the Product Backlog items are to be built during the Sprint for the Increment
• Forms the Sprint Backlog from the selected Product Backlog items and the plan of how to deliver them
• Re-negotiates with the Product Owner if too much or too little work has been forecasted for the Sprint
• Invites anyone else who can provide domain knowledge or advice relevant to the work at hand

During The Sprint

• Work collaboratively together to transform the selected Product Backlog items into the potentially releasable Increment by the end of the Sprint
• Synchronise their efforts via a Daily Scrum to inspect the work so far with respect to the Sprint Goal and adapt accordingly. Additional detailed and informal conversations can also help to synchronise activities as needed, often immediately after the Daily Scrum
• The Daily Scrum format and structure is set by the Development Team
• Collaborate with the Product Owner, if the work turns out to be different than expected, to arrive at something of value and achievable within the Sprint that contributes to the Sprint Goal
• Implement any improvements to the approaches as appropriate

Sprint Review

• Collaborates as part of the Scrum Team with the stakeholders to determine what is done
• Discusses what went well, what problems were encountered and how these problems were resolved during the Sprint
• Demonstrates the “Done” work and answers any questions about the Increment
• Projects likely completion dates based upon the progress so far
• Collaborates as part of the Scrum Team with the stakeholders to determine what to work on next as an input to the next Sprint Planning event
• Collaborates as part of the Scrum Team to adapt the Definition of Done
• Participates as part of the Scrum Team to review how the market place or potential use of the product may have changed, and what is the most valuable thing to do next
• Participates as part of the Scrum Team to review the timeline, budget, potential capabilities and market place for the next anticipated release of the product

Sprint Retrospective

• Collaborates as part of the Scrum Team to inspect itself and determine improvements that can be implemented in the next Sprint
• Collaborates as part of the Scrum Team to enhance quality by refining the Definition of Done as appropriate

Attributes

The key Attributes of the Development Team include:

• Cross Functional skills that complement each other in the team are useful – avoid thinking that this means multi-skilled individuals, as the intention is that everyone brings some deep skills to the table for the team as a whole to be cross functional
• ‘T’ Shaped skills describe team members with a primary specialised skill (vertical part of the T,) in combination with other secondary less specialised skills, (horizontal part of the T.)
  • This allows some resilience in the team as they can become multi configurable and support each other even if the nature of the work is not related to their primary skill set.
• Self organizing teams have a more efficient approach to making decisions and coordinating their activities.
  • This behaviour needs a safe and supportive environment and can take a little while for teams to feel safe enough to make their own decisions. Hence, some long term leadership investment to support and enhance the current culture may be needed in traditional organisations.
• Autonomous and independent teams can make their own decisions and transform Product Backlog items into potentially releasable Increments more effectively, as they don’t depend on others to complete things to a satisfactory level of “Done”.
  • This correlates with cross functional teams to ensure that a team has the ability and the authority to complete the work without interference and dependencies.

Practical Tips

Product Developers	In The Scrum Guide all members in the Development Team are termed as “Developers” which can be confusing when working with traditional IT skill sets, as this refers to anyone who is working to produce the product Increment including software developers, testers, user experience designers, business analysts etc. etc. It can be useful to think of the Development Team as product developers, which might be easier when communicating who and what they are in a traditional organisation transitioning to Agile.
Team Size	The Scrum Guide also offers some guidance on team size, which should ideally be between 3 and 9 people. Smaller teams tend to collaborate more and can be more effective than big teams but may be narrow in available skills in the team to deliver a releasable Increment, and so best to ask the Development Team as to how big they think they need to be to be effective.
Team Balance	Balance in a team can be important in that the correct mix of skills in a team should reflect the nature of the work and what is needed to consistently produce releasable Increments with no part done work left at the end of the Sprint. Having consistently part work done at the end of the Sprint that “carries over” to the next Sprint may be an indicator of an imbalance in the team, Product Backlog items being too big or sub optimal Sprint Planning activities.
Large Teams	Multiple teams on a program of work tend to work more effectively than one big team, and is discussed in Scaling Scrum.
Equal Voice	The best performing teams know that they have an equal voice and feel safe enough to be able to provide their professional opinion freely, try experiments and prototype, and make decisions about how they deliver selected Product Backlog items.
No Sub Teams	The accountability to deliver the work belongs to the Development Team as a whole and should not be partitioned or owned by sub teams or individuals

For more information on the role, consult the Scrum Guide.

See Also

• Scrum Roles
• Product Owner
• Scrum Master