Warning: Creating default object from empty value in /home/garryhan/public_html/59secondsagile.com/wp-content/themes/Consulting_Pro/admin/main/inc/class.redux_filesystem.php on line 29
Development Team Size In Scrum - Part 2 - 59 Seconds Agile

What is the Ideal Development Team Size In Scrum Projects? What happens if the Scrum Team size is too small or too big? Are there any consequences for the Agile Project?

************************************************************************

Ideal Scrum Team Size

A 59 Seconds Agile Video Animation
Ideal Scrum Team Size with 59 Seconds Agile

***********************************************************************

************************************************************************

Development Team Size In Scrum – Part 2

A 59 Seconds Agile Article

Development Team Size In Scrum: Splitting Teams

At a certain size, it may benefit a team to split into 2 smaller teams. However, this is not a trivial decision. When splitting teams, there has to be a new administrative layer. In order to coordinate these 2 smaller teams for the same goal, the organization must conduct a Scrum of Scrums. This extra logistical step has some overhead that the teams must anticipate.

If a team splits too early, the resulting teams are too small. As with any small team, this may result in missed deadlines and failure to deliver value. Waiting too long to split wastes time. Instead of working effectively and minimizing meetings and communication, teams might spend less time developing and more time keeping all team members up to speed. The splitting process takes effort but can benefit a team if performed at the right time.

59 Seconds Agile - The Scrum Team Size
59 Seconds Agile – Development Team Size In Scrum

Development Team Size In Scrum: Changing Team Size

Even if a team isn’t too small or too large, changing the team size does have an effect on developers. As teams grow, developers spend less time writing code and more time communicating and meeting. Small changes in this balance are expected and do not become an issue until developers have too little time to write software. However, developers must anticipate that shift. For every new team members, developers must realize that there will be less time allocated to new development.

Tasks may take more days because the developers have less time each day to write code. Additionally, the team must decide which developers work on which tasks. Scrum teams (Scrum Master, Product Owner and development Team) are self-organizing, but each developer has different skill sets. It is important that each developer work on what he or she knows best. In this regard, a growing team takes the weight off the developers but does add overhead to the project management process.

Development Team Size In Scrum: Shrinking Teams

Shrinking teams put more weight on developers. With fewer developers to work on a project, each remaining developer has greater responsibility. However, with fewer people on the team, there are fewer liabilities. Smaller teams require less time communicating, and thus developers can spend more time writing code. This may increase their velocity, and improve the quality of work that developers can do.

Scrum teams can be large or small, but the size of the team has a great effect on developers. Teams that are too small or too large are inefficient. Changing the team size introduces a new dynamic that developers must deal with. It is important that any team select the size that best fits each organization and project.

Prev <— Continue Reading —> Next

Learn More: Estimating and Planning User Stories

************************************************************************

************************************************************************

User Stories Applied

A 59 Seconds Agile Book Review

User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.

Prev <— Continue Reading —> Next

Learn More: Estimating and Planning User Stories

************************************************************************

************************************************************************

Estimating Scrum User Stories

A 59 Seconds Agile Infographic
59 Seconds Agile - Estimating User Stories
59 Seconds Agile – Estimating User Stories

Prev <— Continue Reading —> Next

Learn More: Estimating and Planning User Stories

************************************************************************

Our Favourite Agile Books

We found these books great for finding out more information on Agile Scrum:

Prev <— Continue Reading —> Next

Share
Translate »