What is your Team's Velocity?

Here is a question all Scrum Masters are asked at one point or the other..."What is your team’s Velocity?"

Most likely answer…"We don’t know! cause we don’t close our stories end of each sprint" Or "We close stories from multiple sprints in one go"

Most likely reaction…"WHAAAAT!!!"

Here are few questions we can ask ourselves to improve on this – not necessarily aimed at figuring out a number (aka Velocity) at the end of each sprint but to be able to ‘deliver value’ end of each sprint and stay true to Sprint commitment. 

• Do we have a Definition of Done for our team? – realistic, agreed and reviewed frequently by the team
• Do we have a Definition of Ready for backlog items? – again, realistic, agreed and reviewed frequently by the team

What prevents us from closing stories/completing work?

• Are we cross-functional as a team?
• Is the team stable and doesn’t change from Sprint to sprint or frequently?
• Are we phase gated from DEV-> Test -> Deployment?
• Stories are not sliced properly? 
• Do we need to review our estimations? 
• Environment issues?
• Do we have automated code integration and deployment set-up (CI/CD)
• Dependencies not aligned? – external and internal 
• Quality of work – unit testing, code scans, peer-review, demo to Product Owner, etc
• Defects from Release specific testing (Integration, Business verification) etc impacting team in mid-sprint i.e. post commitment 

If you are a distributed team, expand on few more questions around your team's set-up 

• Do we have a proper means of engagement/communication channels?
• Sufficient overlap time – if you are in different time zones 

Answers to these (any many more such questions) would vary depending on your organisation’s/team’s technical maturity, leadership’s willingness to support/sponsor, set-up of your team, vendor agreements, priorities of the organisation etc but first step is to know where you stand at the current momenet in time - which in itself is a win.

Treat the outcome of the discussions as any other agile initiative, prioritise and work on them iteratively.