The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Vikas Hazrati on Oct 14, 2008
In Scrum, every team member is important and contributes to the overall velocity of the team. An absence, planned or unplanned, can adversely affect the velocity of the team. An interesting discussion on the Scrum Development group tries to discuss ways to deal with the situation.
Most members of the group agreed that if the absence is known before hand, then the velocity of the team should be reduced proportionately. Hence, less stories should be committed for the sprint backlog. However, if there is an unplanned absence during the sprint and the impact would be considerable, then the scrum master should inform the product owner and negotiate a reduction in the scope.
Some members suggested innovative ways to handle absence. Kiran Thakkar suggested planning for only 85% of the team time, rest 15% is usually enough to handle unplanned contingencies. On similar lines Geir Amsjo added that his team plans for a 6 hour day, rest of the time covers unexpected situations like short sick leave, normal leaves etc.
Dave Smith suggested that he has seen some XP teams effectively absorb the absence of a team member. They do this by reducing the noise in the team space and hence allowing more effective pairing time. He also mentioned that in situations like these, members on the team work harder to reach the sprint goal thus compensating for the absent team member. Ron Jeffries, however commented that if that was true then there is a strong chance that the team is under-committing, according to him the absence of a team member should surely affect the velocity of the team and it would be hard for the team to meet the sprint goal unless they had under-committed the goal at the start of the sprint.
Angela Druckman suggested, that in order to make realistic commitments about the sprint goal, she collects the data on number of available hours of each team member for the next sprint and takes it to the planning meeting. This allows the team to have a look at the total time-off for the upcoming sprint and the amount of work they should commit as a group. However, if team members with special skills are away during the sprint then the product owners should be made aware of their absence so that they can select and prioritize the work accordingly.
Mike Youngtai talked about the using concept of ‘Focus Factor’ in his team. Focus factor is a ratio of story points done to the actual man hours worked. According to him, the focus factor is tracked over a 3 month average and is used in the sprint planning meeting. During the planning meeting the team members calculate the number of man days available and commit to a backlog on the basis of focus factor.
James S. Fosdick shared an interesting idea to deal with unexpected absence, he suggested
When dealing with unexpected absences due to sickness etc. you can deal with it the same way you deal with emerging work. Figure out what the impact will be and see if it affects the sprint burndown (a serious absence will likely noticeably flatten out your sprint burndown). If it does renegotiate the scope and/or commitment with the P.O. If it doesn't no problem.
Agile Development: A Manager's Roadmap for Success
Agility at scale, become as agile as you can be
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
Nice article.
I faced this "absence problem" in our agile projects as well. Most of the time we were able to find a balance as we always had our PO pariticipating (like a chicken) in the daily standup's.
If the PO is not pariticipating in everyday standup, then i think the Scrum Master should rightway convey the news to PO and make him aware of the situation.
Regards
Balaji D Loganathan
I would agree there should be no late surprises or rather no surprises for the PO.
Btw, I was having a discussion about this with a colleague of mine and he just happened to mention "Is there a case where the velocity increases during absence? Does it tell anything about the person who is absent?"
I did not face a scenario like this but it is an interesting question nevertheless! :)
You jest, but it is actually a very -important- question, and one all companies, Scrum or not, need to ask themselves.
Some employees do slow down projects. Bad ressources ARE common, and they drag everyone down. All teams of a certain size have them. When someone takes a 2 weeks leave, and velocity doesn't move, or improve, you need to look at how much work it took for people to pick up the slack. If the answer is "none", you know you need to either train, or fire someone.
..."Is there a case where the velocity increases during absence? Does it tell anything about the person who is absent?"...
Actually... I recently co-taught a CSM course with Jeff Sutherland and he cited a study from a company in Sweden (I believe) on this subject. They found that having one person missing on each team each Sprint actually increased the Velocity of the team overall. The theory was that the Velocity increase was an emergent result of the team becoming more effective at sharing/absorbing knowledge because of the impending absences. They considered the study neither complete nor conclusive, but results were encouraging.
I have noted on my teams that Velocity will often spike a bit (up to 20%) when someone is unexpectedly absent. It is rare for me to see a single team member's unexpected absence to cause a Velocity drop outside normal variance. I have found that the unexpected absences help shake teams into collaborating effectively who may have otherwise been reluctant to share the work.
In my observation, it has never been an indictment of the person who is absent.
"Is there a case where the velocity increases during absence? Does it tell anything about the person who is absent?"
There is actually - it happened in one of our teams. We had this very good analyst that was absent during the whole sprint due to personal issues. In the retrospective meeting we saw that the team had made MORE points than the average - they even finished the sprint earlier and picked a few more unplanned stories. The jokes on the absentee were somewhat funny until we finally realized why that happened - the team had four members, pairing most of the time; with one absent, the three of them didn't match the pairs accordingly, doing a lot less pairing than expected, and thus more work. We finally realized that the increased velocity could have been a BAD thing - we knew the stories were done and accepted by the Product Owner, but the lack of pairing could have caused some quality issues and did cause some handoff waste. That was an isolated case, the team handled absences and pairing much better after that, but this may happen nevertheless.
Something strikes me as funny with the question - like perhaps the people who are asking it might be (unrealistically) expecting that the team's velocity should remain constant with every sprint. Particularly with the suggestion to only factor in 85% of time. I have to ask, 85% of what? If you're planning with story points, then the team's velocity will tell you that the team averages X story points per sprint. That velocity means "this is what the team can deliver in a typical sprint" - it already reflects whatever % of productive time the team is able to provide (be it 85% or 100% of 15% - on average, the team is able to obtain a certain level of productivity and that results in the delivery of roughly X story points per sprint).
And so, I wonder if team member absences don't also get factored into that equation in a similar manner? If, in a typical sprint, team members are typically out for an average of 15% of the time - wouldn't that just get factored into the team's velocity? Sure, there will be greater absence on some sprints - and those will produce fewer story points, but then there will be lower absence on others - and those will produce more story points. That's why we work with averages.
Or have I oversimplified this too far?
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
6 comments
Watch Thread Reply