Jon Archer is a software professional with over 15 years experience who is lucky enough to work out of his mountain retreat high above Denver in the Colorado Rockies. He has worked as a software engineer with various technologies during the course of his career as well as a couple of diversions managing teams. These days he is the scrum master for a challengingly distributed team with members in Massachusetts, Colorado and Hyderabad India. He is a passionate believer in agile principles and is a key advocate thereof for his current employer Perceptive Informatics. He blogs at http://www.jonarcher.com/ and tweets as @9200feet Jon is a DZone MVB and is not an employee of DZone and has posted 19 posts at DZone. View Full User Profile
Calling something average is one step removed from calling it mediocre.
But in the mathematical sense, especially when applied to a team’s
velocity it’s a good thing.
One of the certain tricky bits for any new team trying out scrum is
establishing the team’s capacity. That is, without an historic record of
how many story points of work a team can complete you are somewhat in
the dark as to what to aim for come sprint one.
For a team that’s been working together in the past but not estimating
in points it’s possible they may have a fairly accurate gut feel for
things, and that can be your guide. There’s likely still the novelty of
having not just to develop but also test, fix defects and truly complete
(according to your definition of done) but, with experience of working
together in the past a decent guess can be made.
For a newly assembled team however, or one that’s less confident in
figuring out how much of the backlog to bite off initially, my advice
would simply be don’t worry. Just pick more than enough and accept that
you won’t make it all. From what I’ve seen the first few sprints are
very much a learning experience and part of that learning is going to
include figuring out your capacity.
Given just three or four sprints the team, with good coaching and
guidance from a competent scrum master, will have figured out a number
of recurring key items: big stories are bad, transparency between those
that code and those that test is key, getting things “done” means
limiting how much you work on concurrently and, ultimately, a reasonable
average velocity to work with for planning future sprints.
The team I am currently working with had quite an erratic velocity
initially: 16, 8, 49 (yes really!) and then 26 points. After this we
have stabilized nicely with an average of 24 points a sprint.
This “we dunno, we’re just gonna try it and see” approach to working out
a team’s capacity for quality work is inarguably logical. However it
doesn’t necessarily sit well with those from a command and control
background, especially those with management responsibilities for the
team new to scrum. They like detailed planning. Predictability.
Commitments. Maybe even punitive action against teams that “fail”.
This is completely the wrong approach.
Like it or not, this is when managers need to decide if they are truly
supporting scrum or not. If you are, then step up. Provide the
environment your team needs in this early phase of the adoption. Make
them comfortable with the new regime of trying, reflecting, learning and
improving. Without that support you will stifle their ability to
rapidly improve, and in turn lead to a less than stellar scrum
implementation. Maybe even to a failed one. This happens a lot, and
people revert to traditional, comfortable but ultimately unsatisfactory
approaches to building software. Don’t let this happen to your team.
Create the right environment and harness the power of average.
Published at DZone with permission of Jon Archer, author and DZone MVB. (source)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)