Running a marathon is much like maintaining velocity on a long-term development project. For athletes, a variety of factors influence performance, from hydration to lung capacity. The same can be said for development teams. Team depth, experience, meeting frequency and communication can equally impact team velocity.
Velocity can be daunting to forecast. The teams who master the art and science of establishing and maintaining a development cadence can improve project outcomes through closer scope, timeline and budget adherence.
MentorMate Project Manager Katie Long shares 4 strategies for managing software development velocity.
1. Schedule an Internal Kick-Off Meeting
For project managers, it’s useful to begin gauging team experience and project expectations even before beginning work. Set up some time with the account manager or a stakeholder with deep knowledge around expectations for the development team and existing goals.
Aligning early ensures project leadership will be able to push the development team to fulfill project goals in order of importance for stakeholders.
Internal kick-off sessions between account managers, project managers and development leads also present the opportunity to discuss the skill and capacity of team members who will be assigned to the project, providing early insight into expected velocity.
2. Organize an External Kick-Off with Stakeholders
It’s important to discuss, goals and expectations for how the client can offer feedback to assist in managing software development, especially if the stakeholders or client with ownership for project completion aren’t familiar with your process.
Some project leadership teams have found success connecting the development leader with the key stakeholder to begin building a relationship, removing barriers between layers of project communication and setting the standard for transparency throughout the project. This is especially important when stakeholders need to make decisions that affect project velocity, like ramping up staff once average completion velocity has been set.
3. Gauge Initial Velocity after the First 3 Sprints
Allow past results to predict future velocity in managing software development. After three sprints, it’s fair to assess the velocity of the development team. The team has normalized, and completion patterns have been established. Consider whether the team is meeting the expectations set forward in sprint planning. Compare the projected velocity of story completion in JIRA (or a similar project management tool) against the delivery timeline.
If forecasts show the team stretching to complete the deliverables by the set date, explore the unknown variables that may be impacting their pace.
- Is member time split between conflicting tasks?
- Do they have the experience necessary to complete the work on pace?
- Are personal relationships impacting focus?
- If your team is working with existing code, does it require additional effort not captured in sprint documentation?
If expected completion extends beyond the timeline allocated for the project and all team members are performing to maximum capacity, ask stakeholder/client partners what the team should prioritize.
Example scenario 1. Developing all functionality is important, but team members cannot be added. Consider a timeline extension.
Example scenario 2. Budget and timeline are equally important. Consider launching a leaner version of the solution than originally expected.
By maintaining open lines of communication with project leaders, the team can use initial velocity predictions to forecast and adjust team size, timeline or scope to deliver on what’s most important.
4. Use Meetings to Problem Solve Around Barriers
The Agile process and structures limit the percentage of time teams spend coordinating as opposed to completing work. A planning session is used to kick off each sprint (typically every two weeks). A sprint review is held after to demo completed stories and discuss the acceptance of work along with milestone progress. Stand-ups are held daily. Use Agile ceremonies, particularly the sprint reviews and daily standups to probe any barriers to completion the team faces to avoid negative impact on velocity.
In managing software development, three high-level variables can usually be found at the root of all project blockers: people, process and tools.
People. Team members with less contextual familiarity of the problem can hamper the progress of all. If skills are a barrier, set aside time for supplementary education. Investment at the beginning of a project can make sure incorrect assumptions don’t derail it later on.
Process. Process drives project accountability, clarity and communication. As the project progresses, assess outcomes and tweak meeting dates, lengths or times for efficiency.
Tools. Blockers can be related to connectivity or hardware. Check-in with the team to make sure they are powered by tools of the caliber they require. Sometimes simple changes, like upgrading from a free tool can yield meaningful gains.
Weekly auxiliary meetings between the project manager and the development lead, can provide added insight into the temperament and progress of the team.
Why Predict Development Velocity?
Stable velocity allows stakeholders to make business decisions based on development progress and predict future capacity needed to complete deliverables.
