Month: April 2014

Capacity Based Velocity Calculation for Dynamic Agile Teams

Traditionally the velocity (V) of agile teams is calculated as number of story points (SP) delivered per sprint. If our team is static, that means, it consists of the same or at least the same amount of people in each sprint we can get a velocity that really reflects the team performance.
Although highly desireable, from my experience static teams are not very common. In fact most teams have a certain degree of dynamics, especially in long running projects.

Typical reasons are

  • Vacation or sick leave
  • Daily business (especially team members from the business are not 100% commited to the project, as they still have their daily duties)
  • Partial engagement (specialists are only part of the team when their knowledge is required)

How can we calculate the velocity for those dynamic teams? By taking capacity into account and combining it with the team velocity. I can recommend following procedure that I used on several projects with very good results.

  1. Have a sprint planning meeting with all people that might have something to deliver in the next sprint or delivered something in the previous sprint.
  2. Ask every person how much days she plans to commit to the next sprint. This is the planned capacity (PC). Adjust PC if necessary during the sprint planning session based on the selected user stories. Use PC as a basis to plan the next sprint.
  3. Ask every person how much days she really committed to the previous sprint. This is the delivered capacity (DC). The delivered capacity might differ from the planned capacity announced in the previous sprint planning metting. That is normal for the reasons given above.
  4. Calculate the capacity based velocity like this CBV = SP/DC.

The advantages of capacity based velocity are:

  1. It is based on empiric data (delivered capacity instead of planned capacity). It reflects what really happened and not what was supposed to happen.
  2. It grounds story points (virtual) with capacity (real) as it takes capacity into account in addition to the story points. But beware! Once the SP/DC ratio (how many days do we need to implement a story point?) is known after some sprints, it is tempting to perform planning with capacity instead of story points. This is a bad idea as it brings us back to the notion of exact planning which we (hopefully) learned is not possible.
  3. It allows the projection of realistic project release dates as we have a stable measure even if the team structure varies.

 

Understand your Team with SCARF

If you are a Scrum Master or coach you might sometimes wonder why people act and react the way they do.
The SCARF model can help you to understand which factors are driving peoples reactions.
The model lists factors that cause a reaction of either approach or avoid. The factors are:

Status, certainty, autonomy, relatedness and fairness

Here are some ideas what you can do to minimize reactions of avoidance in your Scrum team:

  1. Increase status by praising sprint results as well as team improvements, ideally in public.
  2. Increase certainty by protecting the sprint from outside disturbances. Make sure the expectations are stable and understood.
  3. Increase autonomy by letting the team take decisions.
  4. Increase relationship by colocating the team members. Select team members by personal interests as well as technical expertise.
  5. Increase fairness by treating yourself and the team members equally.

Keeping those factors in mind can help to better understand peoples reactions and adapt your own behavior so that it minimizes reactions of avoidance.

Team Complexity – The Underestimated Factor

Most people would agree to say that an IT project is complex if it has to cope with difficult technology and a challenging business context.
But it is not just technical complexity that threatens the success of a project. Team complexity is an important and often underestimated factor that highly affects the likelyness of success and failure of IT projects.
Even if you have a simple technical problem to solve, it can get much more complicated if you do it with a complex team.
The main problem is that effective communication is very hard to achieve with complex teams. But effective communication amongst the stakeholders, developers, business and operations is one of the key success factors for IT projects. Thus having a team with low complexity reduces risk and increases efficiency. But why is this often not recognized? I think the reason is that dynamic effects are hard to measure and invisible most of the time.
Inspired by the article Projects fail due to dynamic complexity (German) written by Prof. Dr. des. oec. HSG Stefan Grösser I thought about common factors that affect team complexity and therefore dynamic complexity.
To create more awareness in terms of those factors and make the subject more tangible I’ve created the Team Complexity Calculator. Its a fun tool that can be used to get a better idea of how those typical factors affect team complexity. It does not produce absolute results, so please don’t take it too serious. 😉
If you know additional factors that affect team complexity, please let me know.

Those factors are based on experience I’ve made in projects ranging from small to very large sizes.