Category Archives: Agile and Scrum

Interpreting your agile team’s velocity from a mathematical perspective

This has always been a contentious topic and one which has always been up for debate in all the companies I have worked for.

From my understanding, a sprint velocity is supposed to be an approximate, and not an absolute measure, on what a team can accomplish within a given sprint taking into consideration certain assumption and environmental factors.   This number, from my understanding, is simply a guideline but should not be used to solely determine what a team can accomplish in future sprints.  Some teams view this number as sheer complexity of the task.  Others view this number as a combination of complexity and effort.  The beauty of agile is each team decides how exactly they want to interpret this number.   That’s an internal implementation of the team.  For the sake of this exercise, we will view this number as relative complexity of a task at hand, which somewhat is related to effort assuming no external factors.

For our Rabbit Hat Mechanics agile team,  let’s model a sprint as follows:

y = ƒ(c_1x_1,c_2x_2,c_3x_3, c_4x_4)   where

  • x_1 = previous points from last sprint
  • x_2 = number of staff on holidays or sick
  • x_3 = team familiarity with tooling and working environment
  • x_4 = environmental stability

and c_1 to c_4 and constants.

I have modeled a sprint using four possibly independent variables but each team is different and some could possibly be modeled using more than four variables. Some could be

  • x_5 = capacity of team leads
  • x_6 = quality of scrum master/manager
  • x_7 = number of company meetings
  • x_8 = quality of requirements

This is multi-variable equation with several input parameters one of which is the previous sprint velocity.  The point here is, since human resource management is never an absolute science,  is more of a nonlinear and possibly nth order differential equation, one can appreciate that the previous sprint velocity is just one factor, albeit a heavy one, which should go into the equation while determining what the team can deliver.

When folks advocate for the fact that the previous sprint velocity of, say x_1, should be the only variable or determinant to be considered when determining the next sprint throughput, what they are effectively saying is that the above equation reduces to a linear one in the form

y = ƒ (x_1)

and from my experience dealing with people and teams, this is simply not the case. Humans are not robots and even with robots, there is usually a discrepancy between theory and reality and that x_1 = 40 points from the last sprint will not necessarily be the same number of points a robot can accomplish this sprint taking into consideration external factors.

So, I am saying treat the sprint velocity for what it is:

A parameter, and not the only parameter, which you should take into consideration when determining the team’s potential through put for next sprint.


Sprint story work break down – how do you do it?

Every agile team appears to break down the tasks involved in completing a sprint story item a little different  Also, every team  appears to have a different perspective on the Srum Definition of Done.  My perspective aligns closely with one of my previous manager’s definition:

A story is considered done, if it is shelvable, packageable and shippable.  Basically at the toss of a hat, it can be deployed to production or made available to end customers with all associated artifacts including supporting documentation.

This is the philosophy which I use as guideline when confronted with the task of splitting down sprint stories.  And why so?

Let’s start by stating the assumption that we have a story with a well written, understood and itemized set of user, technical or deployment requirements. These requirements should drive both development, test and documentation.  Or should they?

When a story is considered done, it should be possible to validate that each requirement was met, including existence of a shippable component to end customers, whoever they may be.   Such that at the end of the sprint, the team collectively as a whole, including PM and additional stakeholders should be able to validate that each of the requirements listed in the story is appropriately captured in the resulting artifact.

There are various distinct developmental tasks involved in taking a marketable idea from concept to market.  These tasks include:

  • Design : captures some high level design activity including UX work for UI related stories.
  • Development : everyone knows what this is all about.  Yes, this is the task which captures all coding effort.
  • QA: everyone also should know what this is about.   Someone has to validate the output from the Development tasks to ensure it does meet user requirements specified in the story. An interesting point of contention I have run into involves the source document from which QA should author test cases.  One school of thought says test cases should be driven from user requirements in the story and another says  from the output of the design task. This alone is an interesting topic on its own.
  • Deployment : this task captures work such as creating of chef scripts or other activities dedicated to ensuring code makes it from the build machine into our production servers.  Some companies use DevOps engineers for this.  Others get the same developers to do it all.  Again another interesting topic on its own.
  • Documentation: almost a task which never gets the time of day, especially if product is targeted to internal customers.

On one team, we had a hard and fast rule stating that EVERY story should be broken down into each of the aforementioned subtasks.  However, as with a lot of things in life such hard and fast rules do not apply and often times completely break down, forcing the team into a “process oriented as opposed to goal oriented mindset” as one of my team members  succinctly puts it.  I see these tasks as mere guidelines. Completing some stories will require all of these subtasks while others will not and it is up to the Scrum master in consultation with the team to use wise judgement to make this decision.

Should these distinct activities be captured by individual JIRA subtasks?  I personally think so.  Individual subtasks allow distinct teams to start the work in parrallel, enabling early engagement by all respective teams, possibly allowing for faster delivery of the feature.  Of course, the assumption here is we have distinct teams responsible for each facet of the development workflow.  If we have a single developer responsible for orchestrating each of the aforementioned phases, it is no necessary to explicitly break down the story into such tasks even though it may be worth capturing the effort required during each stage of the workflow.

What do you other Scrum Masters do?