The boundary between product development and solutions development is shrinking, in the context of agile development. When you adopt and practice agile in it's true sense, right from coming up with a roadmap, creating a release plan, breaking the release plan into iterations / periodic releases to how you actually run an iteration or a release - there is actually not much of a different between a product development team and a solutions development team.

 On this premise, I've been part of few discussions questioning the relevance and purpose of "Velocity" especially the usage of it, in the context of product development vs solution development. These discussions prompted me to take a step back and ponder over the very concept of "Velocity":

Purpose of velocity
  • How long it would take for the product / solution to be completed and derive associated cost
    • Raw velocity exercise is a common technique used during release planning
  • How much work (in terms of story points) can be planned in an iteration
  • Important metric that’s used as a continuous improvement measurement at team level
  • Evaluate performance of the team / individual (or dev pair)
What happens in reality
  • Teams normally fall short of planned velocity across different iterations - they either extend the release timeline or get into scope negotiations and / or prioritisation
  • When used as a tool to evaluate performance, it’s normally used in negative connotation and teams tend to compromise quality or functionality to meet the planned velocity
How does the teams / management reacts if the planned velocity is not met 
  • Retrospectives and management meetings to discuss at length 
    • why team couldn’t achieve planned velocity
    • how to improve velocity
    • teams / individuals indulge in blame game, tries to find scape goats, how to protect one’s own interests in front of management and in effect it gets into a downward spiral and agile gets blamed in the end
Can we successfully manage a product / solution delivery without worrying about velocity?  

#1: Self organised teams are expected deliver to its full potential every iteration;  the collective output at the end of each iteration is the best the PO can get, without having the need to track the velocity. 

  • And it would only get better with time, given the team members stay longer and gain more in depth knowledge of the domain / product / solution
  • Over time, the entire ecosystem of the project team, Product Owner and the management would work in tandem 

#1.a: If the PO comes up with a minor change mid-iteration or a major change mid-release, he/she must provide the following critical inputs:

  • business imperatives of the change
  • critical business value that will be delivered by this new / change request (or lost opportunity by not picking up this change request) 
  • is there any major business impact due to change in release timeline
  • finally, what other feature can be traded off or delayed, if timeline is a constraint

In this scenario, velocity really becomes secondary (please note: not necessarily irrelevant or insignificant) as it’s the business that’s really influencing the decision.

#2: On the contrary, a. if the team is in early stages of agile adoption and / or if the agile adoption is not by choice but by an organisational mandate OR b. agile adoption is by choice, but only in parts of the entire ecosystem, velocity becomes one of the important metrics to track and act upon.  

The objective of this workshop is to make the participants first unlearn the wrong interpretations and usages of 'velocity' and make them understand and appreciate the right implementation of velocity through couple of group exercises.  

 
1 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Quick rundown of common symptoms of wrong implementation and usage of velocity - 15 minutes
  • Exercise / game #1: Role play of a real-life project scenario with the wrong implementation of velocity in planning and tracking and the impact on business outcome - 20 minutes
    • Retrospective / Learnings for Exercise #1 - 10 minutes
  • Exercise / game #2:  Re-play the same scenario, setting the right environment/context and correct implementation of velocity in planning and tracking and the impact on the business outcome  - 20 minutes
    • Retrospective for Exercise #2 - 10 minutes
  • Summary - 5 minutes
  • Q&A - 10 minutes

Learning Outcome

This workshop will help the participants unlearn the wrong notions / usage of the 'velocity' and how to apply it in the right way and get the real benefits of this metric.

Target Audience

Scrum Masters, Project Managers, Product Owners, Product/Program Sponsors

schedule Submitted 7 months ago

Comments Subscribe to Comments

comment Comment on this Proposal