As with cycle time, improving the velocity of agile teams requires a holistic approach. Everything’s connected and in such an intricate way that wherever you choose to start will lead you from one point to the next. However, all of the data that you are accumulating with cycle times, sprint burndown charts, and performance metrics can help you identify where to concentrate efforts for the greatest or fastest impact.
Project Requirements: To a large extent, project requirements should define your ideal team composition. This relates to their skills and experience with programming languages, software components, complexity, etc. If your team doesn’t have the skills required for the project, they’ll either need to learn it on the fly or bring in another developer with the skills.
Estimation methodology: How you estimate story points can influence the effectiveness of your planning. There are several estimation techniques like planning poker, T-shirt sizes, the bucket system, and dot voting, among others. For purposes of consistency, it’s best to maintain the same technique across all projects for your team. If that’s not possible, realize that a change in your estimation techniques will have an impact on scheduling.
Changes in scope: The estimation process itself evaluates the work associated with each story point. Avoid changes to the scope of the story point once it has been assigned. The extra work it involves may not be finished by the end of the sprint.
Team Size: As Guy Gershoni discusses, software development team should have 5-8 members. In part, it depends upon the team leader’s management ability. But, the formula: N (N-1) / 2 defines the number of team interactions. With a team of five there are 10 possible interactions; a team of seven expands it to 21; adding two more pushes it to 36 possible interactions. This all weighs in terms of planning the work of each member, meetings, reports, emails, etc. Functionally, the larger your team – the slower it is likely to be.
Team Composition: The more (and longer) you use software development analytics, the better you’ll be able to make data-driven decisions to optimize your team for each project. The Tiobe Index tracks a short list of over 100 software languages, but even teams that regularly only use 4-6 may not have a firm grasp of who knows which language best (or at all). Developers may be reluctant to admit that they don’t know a particular programming language very well.
Cross-Training: Who is on your team is just as important as how many are on it. Each team member isn’t limited to one function. As Guy also discusses, an engineer with experience as a business analyst and QA specialist could fill three roles. Promoting cross-training across your team provides coverage for sick days and emergencies.
Developer optimized-tasks: Break user stories into small, logical pieces suited to the skill of the team member/s tasked to do it. This ties into your “Definition of Done” especially when your team has many junior, but few senior, developers.
Communication and Collaboration: There’s some more “C-words” again! Software development is complex with a lot of moving parts that need to come together. Keeping the Sprint Burndown available to everyone is one way of keeping everyone aligned on progress and what needs to be done. Every meeting is an opportunity for team members to identify barriers and dependencies.