The Agile With Scrum Users Guide PDF

The Agile with Scrum Users Guide:
A Compilation of Thoughts and Practices

Compiled by Joel Adams, CSM
jadams@devonconsulting.com
Edited by Jillian Neustel
jneustel@devonconsulting.com
2006
This book is an edited and organized compilation of over 100 postings to message boards and a few other texts. The
primary source is ScrumDevelopment in Yahoo Groups.
Although the term Agile can cover a wide range, I have always been most interested in people, team productivity,
and project management. The subjects selected for this book and these particular answers and comments were
useful to me in learning about Agile and teaching others about Agile.
-- Editor
ii
THE HISTORY OF AGILE SOFTWARE DEVELOPMENT ................................................ 1

1.1 ORIGINS OF SCRUM .................................................................................................................... 2
1.2 IMPLEMENTATION CHALLENGES ................................................................................................ 4
1.3 AGILE VS. WATERFALL .............................................................................................................. 6
1.4 SCRUM VS. TRADITIONAL SPIRAL DEVELOPMENT...................................................................... 7
1.5 CMMI AND AGILE ..................................................................................................................... 9
1.6 AGILE AND PMBOK ................................................................................................................ 10
1.7 SCRUM WITH RUP.................................................................................................................... 12
1.8 PERSONAL SCRUM.................................................................................................................... 14
TEAM SPACE AND ON-SITE VS. OFFSHORE ................................................................... 16
2.1 BULL PENS / CO-LOCATION / OPEN SPACE (QUIET WORKING CONDITIONS VS. COMMON ROOM)
....................................................................................................................................................... 17
2.2 DISPERSED (NON CO-LOCATED) TEAMS .................................................................................. 19
2.3 ON-SITE CUSTOMER ................................................................................................................ 20
TEAMWORK AND HIERARCHY.......................................................................................... 22
3.1 APPLICATION ARCHITECTURE ACROSS TEAMS ........................................................................ 23
3.2 SELF-ORGANIZING TEAMS ....................................................................................................... 25
3.3 SCRUMMASTER: ELECTED FROM TEAM................................................................................... 26
3.4 SCRUMMASTER: TEAM MEMBER OR COACH ........................................................................... 27
3.5 SCRUMMASTER: COMMUNICATION.......................................................................................... 29
3.6 BUSINESS ANALYSTS AND SCRUM ........................................................................................... 30
3.7 IS THE PRODUCT OWNER A PIG OR A CHICKEN?....................................................................... 33
3.8 INTERACTION DURING SPRINT ................................................................................................. 37
3.9 RETROSPECTIVES: WHO SHOULD FACILITATE ......................................................................... 39
3.10 SPRINT REVIEW: STAKEHOLDERS ROLE................................................................................ 40
3.11 TEAM MEMBERS .................................................................................................................... 42
3.12 PERFORMANCE REVIEWS ....................................................................................................... 43
DEVELOPMENT PRACTICES ............................................................................................... 45
4.1 BEST PRACTICES ...................................................................................................................... 46
4.2 IMPLEMENTING AGILE ON YOUR OWN ..................................................................................... 47
4.3 DAILY BUILDS ......................................................................................................................... 48
4.4 DAILY SCRUM MEETING .......................................................................................................... 50
4.5 SCRUM OF SCRUMS .................................................................................................................. 51
4.6 SPRINT GOAL ........................................................................................................................... 52
iii
4.7 TASK SIZE VS. EFFORT VS. DURATION ..................................................................................... 53

4.8 TASK SIZE (BREAKING DOWN TASKS) ..................................................................................... 54
4.9 SPRINT CALENDAR ................................................................................................................... 55
4.10 ESTIMATES ............................................................................................................................. 56
4.11 ESTIMATING TESTING ............................................................................................................ 57
4.12 PLANNING AND ESTIMATING TASKS ...................................................................................... 58
4.13 TECHNICAL DEBT BIG REFACTORINGS NOT YET DONE ...................................................... 61
4.14 REQUIREMENTS READY FOR SPRINT ...................................................................................... 62
4.15 TESTING ................................................................................................................................. 63
4.16 TEST DRIVEN DEVELOPMENT................................................................................................. 64
4.17 UNIT TESTING ........................................................................................................................ 66
4.18 BUGS HOW TO HANDLE....................................................................................................... 69
4.19 RETROSPECTIVES ................................................................................................................... 70
4.20 IMPLEMENTATION OR CUSTOMIZATION REQUIREMENTS ........................................................ 71
4.21 REQUIREMENTS DEFINITION SPRINT ...................................................................................... 72
4.22 VERY LARGE PROJECTS ......................................................................................................... 74
4.23 SPRINT BURNDOWN ............................................................................................................... 75
4.24 NEW TASKS ADDED TO LIST OF SPRINT TASKS ...................................................................... 77
4.25 PRODUCT BACKLOG ............................................................................................................... 80
4.26 MOVING PRODUCT BACKLOG TO THE SPRINT ........................................................................ 81
4.27 PRODUCT BACKLOG IS A NULL SET ....................................................................................... 83
4.28 DEFINITION OF DONE ............................................................................................................. 84
PRINCIPLES, MEASUREMENTS, AND TOOLS................................................................. 86
5.1 SCRUM PERFORMANCE MEASUREMENTS ................................................................................. 87
5.2 SCRUM PRINCIPLES .................................................................................................................. 88
5.3 DECLARATION OF INTERDEPENDENCE ...................................................................................... 89
5.4 SITUATIONAL OWNERSHIP: CODE STEWARDSHIP REVISITED ................................................... 90
5.5 THE TOP 10 KEY DIFFERENCES BETWEEN A TEAM OF INDIVIDUALS AND A GROUP OF
INDIVIDUALS .................................................................................................................................. 92
5.6 BURNDOWN TRACKING ............................................................................................................ 94
5.7 USER STORIES .......................................................................................................................... 95
5.8 AUTOMATED TRACKING TOOLS ............................................................................................... 96
5.9 REFACTORINGS ........................................................................................................................ 97
5.10 SCRUM ON A PAGE ................................................................................................................. 99
iv
Section One:
The History of Agile Software Development
1.1 Origins of Scrum

Of historical interest is that Scrum was incubated at Easel Corporation in 1993 where I had just joined them as VP of
Object Technology after spending 4 years as President of Object Databases, a startup surrounded by the MIT
campus in a building that housed some of the first successful AI companies.
My mind was steeped in artificial intelligence, neural networks, and artificial life. If you read most of the resources
on Luis Rocha's page on Evolutionary Systems and Artificial Life you can generate the same mind set:
http://informatics.indiana.edu/rocha/alife.html
I leased some of my space to a robotics professor at MIT, Rodney Brooks, for a company now known as IROBOT
Corporation. Brooks was promoting his subsumption architecture where a bunch of independent dumb things were
harnessed together so that feedback interactions made them smart, and sensors allowed them to use reality as an
external database, rather than having an internal datastore.
Prof. Brooks viewed the old AI model of trying to create an internal model of reality and computing off that
simulation was a failed AI strategy that had never worked and would never work. You cannot make a plan of reality
because there are too many datapoints, too many interactions, and too many unforeseen side effects. This is most
obviously true when you launch an autonomous robot into an unknown environment.
The woman I believe will one day be known as the primeval robot mother by future intelligent robots was also
working in my offices giving these robots what looked like emotional behavior to an external observer. Conflicting
lower level goals were harnessed to produce higher goal seeking behavior. These robots were running in and around
my desk during my daily work.
I asked IROBOT to bring a spider-like robot to an adult education course that I was running with my wife (the
minister of a local Unitarian Church) where they laid the robot on the floor with eight or more dangling legs
flopping loosely. Each leg segment had a microprocessor and there were multiple processors on its spine and so
forth. They inserted a blank neural network chip into a side panel and turned it on.
The robot began flailing like an infant, then started wobbling and rolling upright, staggered until it could move
forward, and then walked drunkenly across the room like a toddler. It was so humanlike in its response that it
evoked the "Oh, isn't it cute!" response in all the women in the room. We had just watched the first robot learn how
to walk.
That demo forever changed the way the people in that room thought about robots, people, and life even though most
of them knew little about software or computers. (I believe the robot's name was Genghis Khan and he is now in the
Smithsonian.)
This concept of a harness to help coordinate via feedback loops, while having the feedback be reality based from
real data coming from the environment is central to human groups achieving higher level behavior than any
individual could achieve on their own. Maximizing communication of essential information between group
members actually powers up this higher-level behavior.
Around the same time, a seminal paper was published out of the Santa Fe Institute mathematically demonstrating
that evolution proceeds most quickly, as a system is made flexible to the edge of chaos. This demonstrated that
confusion and struggle was essential to emerging peak performance (of people or software architectures which are
journeys though an evolutionary design space) as was seen in the robot demo.
On this fertile ground, the Japanese Scrum paper provided a name, a metaphor, and a proof point for product
development, the Coplien paper on the Borland Quattro Product kicked the team into daily meetings, and daily
meetings combined with time boxing and reality based input (real software that works) started the process working.
The team kicked into a hyperproductive state (only after daily meeting started), and Scrum was born.
Jeff Sutherland1
From: Jeff Sutherland jeff.sutherland@computer.org; Sent: Sunday, December 5, 2004 at 2:07 PM

Subject: Wholeness
1.2 Implementation Challenges

Hello PaulOldfield1,
Thank you for writing.
> On Thursday, August 3, 2006, at 4:48:34 AM, PaulOldfield1 wrote:
> Yet I don't think this is the root cause, or solution, of the problem Ron was talking about. We've done fairly well
at getting the buzzword of Agile across, but we don't seem to be doing too well at following up with the
enlightenment about what the buzzword really means. IMHO.
Yes, that's certainly what I've just been going on about. I'll give some examples.
Scrum and Engineering Practices
In the Scrum world, the CSM course and the books don't say much about engineering practices. I guess it's assumed
that if the team sets itself to producing real releasable software every month, they'll figure out what the engineering
practices are that will help them do that. I actually believe that to be true, though it's often terribly slow waiting
around for someone on the team to invent testing.
What happens, at least in part because Scrum says so little about engineering practices, is that teams do things that
are far from ideal. A short list:
* Start a Sprint with analysis, so that programmers have nothing to do for a week or so;
* Throw the code to the testers at the end of the Sprint, so that they have little to do at the beginning and are
overloaded at the end;
* Solve that problem by having a development Sprint followed by a "QA" Sprint, resulting in mostly idle people
half the time;
* Solve that problem by having testing for Sprint N during Sprint N+1, reducing feedback and interrupting Sprint
N+1 programmers, and deferring fixes to Sprint N+2, reducing learning profoundly;
...and so on. There are many aberrations. We should produce a list of them. Maybe with a list of things labeled "If
you're doing these things, you're probably not doing it right yet," we could address this enlightenment question.
Agile and Additional Practices
We have a number of Agile brands and branches who are strong proponents of some additional practices. Modeling
is a popular example. Scott Ambler has been visiting lately, and he has an entire "Agile method" which is (was?)
called "Agile Modeling". There are other examples, adding in Use Cases, Modeling, a bit of Up Front Architecture
or Design, and so on.
What is unfortunate in my opinion is that most of these "defensive" additions to Agile are unnecessary, and have the
result of appearing to say that if you are going to do Agile safely, you'd better do a bunch of requirements first, then
some architecture, then some design, then finally code and test the application.
Since people are used to doing things roughly that way, that's what they read. They discover that they're "already
doing Agile", add a couple of meetings to their practice, and proceed business as usual.
Agile Without Experience
There are a lot of people pushing Agile today who have entered the market from some other realm. There are group
dynamics people, PMI people, and so on. Some of these people I want to say many have little or no training
from people in the Agile lineage, and have never been on an Agile project except for projects they have created and
called Agile.
Einstein said: "Example isn't another way to teach: it is the only way to teach. In Agile, that's certainly true. The
best way to learn how much to test is to test too much, not just too little. The best way to learn how much to rely on
up front thinking and building and how much on refactoring is to try to build software without all that modeling and
infrastructure.
People who create methods without ever having worked with or even examined a really well-operating Scrum or XP
project can't possibly know what they would if they had. I think their conclusions and recommendations would be
quite different.
Agile Without Skills
Software development is an intricate and difficult art. Yet as an industry we send people into the fray terribly poorly
equipped. Even developers with degrees in the subject are not well prepared in terms of what is really needed today.
More significant is the fact that many again I'd say most software developers have no significant training in the
subject at all. They're self-taught refugees from some other realm, who have entered programming because it
interested them, or because there were no jobs available for semanticists or whatever they studied in college.
To do the necessary engineering practices mentioned above, Agile teams require an especially wide range of skills,
and the team needs to be really good at them. I would include human relations skills, requirements skills, design
skills, programming of course, how about real Object Oriented programming, almost no one knows how to do that,
relational database skills, and more. Add in customer-facing testing, unit testing, test-driven development, and
refactoring. Add in some skills in setting up builds, and doing code management.
The list is endless, and if we're going to be Agile, we can't have some bottleneck person who is our only refactorer:
we all need to be good enough at most of these things. But there's no focus on these kinds of skills. Scrum, to name
names, scarcely even admits that these skills exist, much less matter.
Now sometimes, Scrum proponents claim "all those things have always been part of Scrum". It's true that all those
things have always been part of //successful Scrum projects//, because they have to be. Authors of other Agile
methods say similar things: we don't mention all these foundational things, they are taken for granted. But so few
people have them, how can we take them for granted? Technical skills are often not part of Agile culture ... and they
need to be.
Summary
Ken and others like to say that Scrum is "common sense". In my experience, it isn't. Jeff likes to point to Scrum
teams that are "hyper-productive". In my experience, most aren't. The reasons have to do with the passing on of
knowledge, and in some cases, the active denial that knowledge is necessary, and the active addition of things that
are only sometimes needed.
The Agile marketplace is filling up with people, mostly of good will, trying to do a good job, who, nonetheless, have
an n-th hand partial picture of what it's all about. Of course, in the end, all of us only have a partial picture of what
it's all about, YT included. And yet, it seems to me that things are getting watered down. Maybe that's inevitable.
Ron Jeffries2
2
From: Ron Jeffries ronjeffries@acm.org; Sent: Thursday, August 3, 2006 at 4:10 AM
Re: Agile 2.0 (2nd Attempt)
1.3 Agile vs. Waterfall

1. The difference between Agile and Traditional Project Management is simple and distinct.
a. Agile is function / goal based that is to say focused on what the product owner and user feel is critical
to their success
b. Traditional is task / cost based that is to say focused on the providing the customer proof that the
resources invested are being consumed according to plan
2. Neither approach communicates needed information to all parties concerned.
a. Agile speaks poorly to customers who want to know where the money went
b. Traditional speaks poorly to the product owner and user as to the usefulness of the functionality being
provided
3. The differences are profound but at the same time driven by the audience each approach talks to.
a. Bottom up support from users, customers, and clients will push organizations to use Agile methodologies
b. Top down pressure by stockowners, investors and will push organizations to remain with traditional
methodologies
4. There needs to be some thought put into building an interface between the two methodologies so that our
customers can better use our skills and we can be seen as useful.3
From: Mike Dwyer mike.dwyer1@comcast.net; Sent: Thursday, January 13, 2005, at 10:35 PM
Subject: Lessons Learned Forward
1.4 Scrum vs. Traditional Spiral Development

I work in an organization that is just (finally) beginning to take an interest in using Scrum and other Agile practices.
One of the questions I was recently asked was "How does Scrum differ from traditional spiral development?" To be
honest, I feel a little stuck. I can probably give some vagueish answers to this, but I'm hoping that someone can
point me to a short article on the web that summarizes the differences with better clarity. Or respond directly to
this email with some bullet points. Any input?
Tobias4
________________________________________________________________________
Hi Tobias-I get asked this exact question quite often in fact, in probably 2/3rds of the Scrum classes I teach. Here are a few
key points:
--Boehm's spiral model is risk-driven. To start each pass through the spiral you determine the riskiest thing and do
activities to resolve that risk (normally code that part of the system). Scrum, on the other hand, is customer-value
driven. To start each Sprint, the product owner selects her highest priority work. This is a very key distinction
because spiral model leads to work on risky items that may not be needed. It also puts the development team in a
mode of avoiding risk instead of a mode of delivering customer value. This doesn't say we ignore risk in Scrum and
often risky stories get prioritized quite highly but risk is not the only or the driving factor.
--Spiral model is iterative but doesn't stress having the same length of Iteration each time. Scrum wants the same
Sprint length every Sprint. This creates a very nice rhythm to the project every 30 days the team knows it will
deliver.
--Spiral projects may or may not produce working code each time through the spiral. During the initial go-rounds it
is entirely likely they won't produce code, or at least won't produce code that lives in the final product. Scrum teams
will.
--The spiral model is really a shortened waterfall if you uncoil it. There are distinct phases. They may overlap
slightly but they are not highly/totally concurrent as with Scrum.
I hope that helps,
--Mike Cohn5
Author of User Stories Applied for Agile Software Development
www.mountaingoatsoftware.com
________________________________________________________________________
Been thinking/reading a little more myself since yesterday, and believe the following two observations are also true:
--A Scrum team is self-managing and self-organizing whereas a development team on a traditional spiral model is
management-driven. Key decisions within a Scrum Sprint are made by the team, collectively, not by management.
--Scrum emphasizes customer involvement at the start and end of every Iteration; spiral, like waterfall, only involves
customers at the start of a project.
Would you agree?
Tobias6
4
From: Tobias Mayer tobyanon@yahoo.com; Sent: Tuesday, December 14, 2005 at 5:45 PM
Subject: Scrum vs. "Traditional Spiral Development"
5
From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Tuesday, December 14, 2005 at 7:24 PM
6
From: Tobias Mayer tobyanon@yahoo.com; Sent: Wednesday, December 15, 2004 at 7:23 AM
<Mike Cohn agreed with Tobias. Here is a differing answer. Editor>

________________________________________________________________________
Hi,
Mike gave a nearly perfect summary for the spiral model.
No, I don't really agree. I would go so far that we have to say: Scrum and spiral model are completely different
approaches, like basketball and ice hockey are two completely different games. Both have projects and especially
software projects in common, like both games are (team) sports
Scrum focuses on a lot of things that I would call "people centric". How to get "people", the team plus stakes
holders, to work together. The spiral model is problem centric. What are the core problems in software
development? Neglecting risk is one. And most if not all other problems can be translated into their associated risk.
I would say the spiral model does not cover questions about how to organize a team. And in fact when you are
doing Scrum, most of the time you do the spiral model as well (or a lot of things similar to spiral model phases),
don't you?
One big difference in the area where Scrum and spiral model overlap IMHO is:
Scrum encourages prioritizing by ROI; its the ScrumMasters responsibility to point out risks (IMHO) (because risks
endanger ROI). The spiral model prioritizes by risk, so the customer/product owner is himself responsible to
identify/remove risks.
But Mike pointed that all ready out when he said Scrum is customer value driven. There is no value and a low
chance of success if the value only can be achieved by taking a big risk and not focusing on how to lower or remove
that risk.
In fact, when one is asking me what is Scrum? Then I answer: a variation of the spiral model. And I give 5 points I
find important corner points (like fixed Sprint length). Probably I always answered wrong?
Angelo7
From: Angelo Schneider angelo.schneider@oomentor.de; Sent: Wednesday, December 15, 2004 at 5:39 PM
1.5 CMMI and Agile

1. Adding XP cant be done because CMMI simply does not provide the means for an Agile-centric development
process.
2. After some more thought and much hand waving, adding Agile can be done because CMMI does not describe the
actual details of implementation.
3. Once over this hurdle, it turns out to be harder than it looks because the two distinct cultures need to be brought
together. Both cultures need to understand each other and search for join points.
4. Then it becomes easier than it looks once the cultural aspects are overcome and the quest for process
improvement and software quality is joined in both cultures.
5. Then it becomes hard again once the first major problem is encountered. The naysayers will naturally say, I told
you not to do that. The supporters will naturally say, Give it a chance, and well work out the kinks.
Steps 4 and 5 will repeat for some time until experience, consensus, and cultural connections are reached about the
benefits, risks, issues, and costs of incorporating Agile in the CMMI framework.
Blending Agile Development Methods with CMMI, by Glen Alleman, in

The Evolution of Agile Project Management, Cutter Consortium Paper, 2004
1.6 Agile and PMBOK

Sounds strange in the same sentence, huh? I want to generate some discussion on the following: Can you use PMI
concepts on an Agile project? I think you can. The main intellectual jump a PMP project manager has to make (I
am one by the way) is that you have to look at the work differently. You cannot view tasks in a plan as delivering
value. In software, you have to look at delivering working code. You get past that, and things are no so different.
We all manage risk, cost, time, integration, scope, people, communication, risk, and sometimes procurement. You
just have to structure these things according to an Agile philosophy and build flexibility into your systems.
I think we need a language for helping the "establishment" understand how it adds value and can complement
existing methods?
Thoughts?8
________________________________________________________________________
I definitely think this is a worthwhile discussion! Having struggled with it, I found some presentations that actually
had some good thoughts. They were done by Rally and presented at various conferences. They go through the
mapping of Agile Project Management and the PMBOK. It makes for some good reading:
Whitepaper: A project manager's survival guide to going Agile
http://www.rallydev.com/kportal.jsp?doc=wp15
Presentation: A project manager's survival guide to going Agile9
http://www.rallydev.com/kportal.jsp?doc=wp11
________________________________________________________________________
What about an APMBOK?
Particularly small to medium size companies can't bear the whole processes suggested by PMBOK.
Cheers,
Adail10
________________________________________________________________________
PMBOK and Agile are completely different approaches to software development.
The PMBOK takes a deterministic detailed approach to project management that can be used (at least parts of it) in
any project be it software or construction.
Agile is a movement based on values and principles (not prescriptions like the PMBOK).
You can be an Agile project manager and look at the PMBOK for "things to consider when managing a project",
however, if you are looking for a prescription on how to do Agile project management you are (IMHO) in the wrong
crowd.
Agile does not prescribe what you must do, just what values and what principles you should look to for guidance,
the rest is up to you.
This is probably one of the factors that makes Agile adoption so hard. People think they can just do stand-ups,
retrospectives, TDD and everything else will work. That's not how it goes... Agile is not a "silver bullet".11
8
From: "mikecottmeyer" spamhole@cottmeyer.com; Sent: Tuesday, August 01, 2006 at 9:48 AM

From: "aggie_melissa2000" aggie_melissa@hotmail.com; Sent: Tuesday, August 1, 2006 at 10:30 AM
10
From: "Adail Retamal" adail.retamal@gmail.com; Sent: Tuesday, August 01, 2006 at 11:32 AM
9
10
________________________________________________________________________
Dear Sirs,
I guess it is important to remember that PMBOK also doesn't dictate what should be done.
As Agile, it is not a prescription. It is a Guide to a set of good practices.
The manager should carry an analysis for each project of what of these practices and in what degree it should be
applied. And it doesn't matter in what industry.
Peter Mello, PMP12
11
12
From: "duarte_vasco" vasco.duarte@f-secure.com; Sent: Tuesday, August 01, 2006 at 12:02 PM

From: Peter Berndt de Souza Mello peter.mello@x25.com.br; Sent: Tuesday, August 01, 2006 at 12:33 PM
11
1.7 Scrum with RUP

When I heard about this article last week, I was curious if IBM would try to portray Scrum as an "add-on" to RUP,
or if they would introduce Scrum as a standalone process with which RUP disciplines/workflows (whatever they call
them now) can be incorporated per the discretion of the team. In other words, is RUP presented as the container and
Scrum the contents, or is Scrum presented as the container process with RUP workflows as (potential contents).
Although at the beginning of the article they seem to give self-organization and "Scrum is a management-wrapper"
lip service, the author seems to forget all of that by the conclusion, which reads:
In general, RUP satisfies organizational demands by bringing a structured and proven process framework to the
table, and Scrum patterns can add additional dynamics to the project.
I'd argue that Scrum, by virtue of it's foundational requirement for team self-organization and empirical process, can
never be contained or absorbed by another process that dictates defined processes, like engineering practices. Can
RUP practices be used with Scrum? Of course! Any team that chooses to do RUP workflows because that's what
works for them, is free to do so under Scrum's self-organization. In this case, Scrum is the parent-process, not a
subordinate process.
But it can't work the other way around: if we are doing RUP our world of engineering practices are limited to the
workflows defined in the RUP. That limit flatly violates core Scrum principles, so you can't add Scrum onto a
process like the RUP as a subordinate, secondary process.
Actually, if IBM treats Scrum as a sanctioned add-on to RUP, and Scrum allows teams to pick and choose their own
engineering practices, doesn't RUP then become "anything the team wants to do". I doubt IBM would want to take
it that far.
Any thoughts?
-- Victor Szalvay13
________________________________________________________________________
Rational Unified Scrum/XP
Marco Abis on the XP mailing list mentions a message-thread on RUP and Scrum/XP on the Scrum mailing list...
Here are some snippets:
Ken Schwaber:14 "Let us hypothesize that having a Scrum plug-in for RUP is an idea worth pursuing. [...] Is this
type of metaphor appropriate for Agile processes, or does this level of delineation lead to them being fodder for M/S
project, for 'hands-off' management, and for robotic tracking of plans while ignoring realities?"
Ron Jeffries:15 "The comments from Rational clearly did not reflect the soul [of XP]. They do not get 'Agile' in my
opinion. [...] Their philosophy, again in my opinion, is based in large-systems experience, old-style 'up front'
thinking, and a command and control orientation. [...] My involvement with the RUP XP plugin was based on my
belief that it would be better with me than without me, and I think it is. Even so, it is still a long way from
expressing what XP is."
Adriano Comai:16 "having been involved in many RUP customizations, I think RUP_Scrum makes sense (much
more, in my opinion, than RUP-XP). RUP needs _exactly_ the Scrum practices to become Agile. As you know,
many shops with an existing waterfall culture buy RUP as an help to move towards a more effective development
approach, and then misuse it."
13
From: Victor Szalvay victor@danubetech.com; Sent: Tuesday, February 15, 2005 at 4:26 PM
Subject: Re: Scrum + Unified Process = ?
14
http://groups.yahoo.com/group/Scrumdevelopment/message/779
15
16
12
Alan Shalloway:17 "You can take a committed dev group (most are) and have them do RUP/Scrum in a way that an
upper management that doesn't want to hear about Agile will accept. [...] here's a chapter discussing this I've just
put on our public wiki (Dan Rawsthorne and I are writing a book on effective software development and this is a
likely chapter). See:
http://www.netobjectivesbooks.com/N_O_BookFeedback_Wiki/owbase/ow.asp?DontTryToSellXP"
Marco Abis:18 "will try to explain why I think so (after years of effective RUP implementations!): RUP is
fundamentally a very, very big framework [...] I will not spend time to write why managers like RUP but not Scrum
[...] makes me think that what managers want is something that isn't really useful to deliver the right project and
often is the first impediment to the project success."
Adriano Comai:19 "Sometimes it's difficult to tell these organizations, who made huge investments into RUP: throw
it off, there are more effective approaches out there, try them instead. In such cases, I believe, it is better to suggest
an improvement using Agile practices in the context of the existing process."
Marco Abis:20 "I experienced a lot of clients (of mine, of course) professing they were implementing an "Agile
version" of RUP but when I analyzed their work I found they were just cutting off some documents feeling "more
lightweight". I definitely think this is one of the main issues: a lot of people believe Agile means just less docs, they
try to cut off some of their docs and then affirm Agile is nothing more than this. As stated by Jim [Highsmith]: they
are missing fundamental understanding of the unpredictability of project activities. [...] For those who haven't read
it I suggest 'Agile Revolution'21 by Mike Beedle.
Marco referred to http://www.crystalmethodologies.org/cgi/wiki?AgileVsSelfAdapting, from which I quote Jim
Highsmith: "So self-adapting, by itself isn't Agile." and Alistair Cockburn: "criticisms of RUP [...] Doing the change
case is very laborious. Just heard of an airline company that wants to use RUP, so they spent 6 months creating a
RUP-for-them. Now every project has to spend 2 months turning that into a RUP-for-the-project. Problem is when
the project is only 6 months long, this is too long."
Another Highsmith quote on that page: "But lightweight is only one aspect of Agile, the other two are collaborative
values and principles and a fundamental understanding of the unpredictability of project activities (although
outcomes can be achieved). Agile is much more than lighter documentation and fewer processes. Rational is trying
to have it both ways still telling corporate managers what they want to hear in terms of predictability, control,
productivity, etc. while at the same time touting that they are 'Agile' also."
17
19
20
21
http://c2.com/cgi/wiki?AgileRevolution
18
13
1.8 Personal Scrum

I wanted to share with you an experiment I've been running for the last several months, in hopes that it might spark
some interesting conversation. It's the use of a modified version of Scrum for managing my life, and through trial
and error it's become quite useful in helping me to do a better job accomplishing goals and filling my life with things
that make me happy.
It started several months ago when I realized that my life bore some striking similarities to a dysfunctional software
development project. Which is to say it was filled with a lot of unclear direction, goals that weren't being met,
responsibilities and obligations going unfulfilled, and important "maintenance" that was being put off again and
again with a net result that "the product" (in other words, the experience of being me) was not all that it could be.
So I set about seeing how Scrum could be applied to improve matters. Here's what over several months I've found
worked well for me.
Sprints last one week, and Sprint Planning takes place Sunday nights. I begin by making an estimate of the time I
will have available to put toward my goals of the week typically, this is about 10 hours (or about 1 hour per day
during the week, and 2 hours each weekend day). My life backlog has at the top of it a recurring list of items that I
consider "must-haves" every week these are the things that I consider necessary for "the good life" for myself or
those around me. I actually have them grouped according to the various personae that comprise "me" husband,
father, son, citizen, learner, body, and so forth. Organizing it this way helps me ensure I don't overlook an important
part of who I am, as I think about what I wish to do in the week; it also allows me to aim for a balance among these
different directions. So, for example, under "body", my standing backlog items might include "take vitamins on 5
mornings", "do yoga on 3 mornings", "get 8 hours of sleep on 4 nights", etc.
The criteria for an item to appear on the backlog is two-part. First, it must be important for "the good life" (now
there's a topic that deserves its own posting if ever there was one). Second, it must be something that might not
otherwise happen. So, for example, I don't need to put "brush teeth" or "go to the bathroom" on the list (or at least I
haven't yet). I began with things that were chore-like (such as taking my vitamins), or which were enjoyable but
required forethought and so I tended to miss them (like organizing an outing for my daughter and me). Over time,
though, I found it useful to include anything that met the basic criteria above. For example, I love playing computer
games, but I was finding that when life got busy, it would be one of the things that got squeezed out. Now it's an
item on the backlog: Play an hour of computer games. It might seem a little odd to in a sense "make a date with
oneself to do something that's akin to goofing off", but if it's goofing off that matters, it should be on the backlog.
Each of the recurring items on the backlog has a time estimate associated with it, and these become quite accurate
over time, since they come up every week.
Once I've gone through the recurring backlog items, I move onto the non-recurring backlog items. These are either
one of the things I need to do ("plan family vacation") or represent small progress against big goals ("complete 1
chapter of mandarin textbook"). I generally only have enough of my budgeted time remaining to commit to one or
two of these items, but frankly, that's one or two more than I was committing to before.
Once I've made my commitment, I print up a sheet that lists the tasks and time remaining, and I post it in a very
visible place in our house (kitchen wall). I'll sometimes talk through it with my wife for a few minutes, as a way of
making the commitment even more visible and "real".
Then, just before bed each night, I'll do my equivalent of the standup meeting looking at the task list, marking
tasks that have been completed, and mentally orienting myself to what I'd like to do tomorrow.
Then, when Sunday rolls around, there's usually a little scramble to complete some tasks, but Sunday morning is
actually a great time to do this. My "Sprint Review" on Sunday evenings consists of looking over the tasks from the
week, and giving myself a pat on the back for what I was able to accomplish, and if there are things I wasn't able to
accomplish thinking about why. This leads into planning for the week ahead. In thinking about the week that's
passed, I can adjust some of the goals for the week ahead. For example: if I've been feeling dragged out, I might
adjust several of the items on the recurring portion of the backlog (increasing 8-hour nights of sleep from 3 to 4, and
14
swimming from 2 days to 3); or if I have a busy work week ahead, I'll cut back my time budget, and make some
calls about tradeoffs.
One of the things I've found is that for this approach to be successful, unbudgeted time must still be preserved. In
other words, the time you allocate to personal Scrum must be only a fraction of the free time you have available.
Happiness depends in part on being able to decide on the spur of the moment to do nothing, or do something
completely silly and unproductive, and do it without any guilt at all.
One of the areas where the approach falls flat is "non-standard" weeks for example, going on vacation, or having
guests visiting, or other situations where budgeting time in this way is undesirable or difficult to do.
Overall, this approach has had a positive effect on my life, and the experience has been similar to that of teams I've
worked with in adopting Scrum: greater sense of clarity of direction, repeated satisfaction of accomplishment,
greater confidence in setting personal goals, and a greater sense of contentment and peace around living up to one's
responsibilities and opportunities.
I'd love to hear about others' experiences with other Scrum or Agile-based life management techniques.22
________________________________________________________________________
Pete,
Thanks for this. It's a really well described account, and an excellent example of the power of Scrum as a simple
means to effect change. I enjoyed reading it.
I have been using Scrum-like practices to organize my daily workload since becoming a consultant. I can get in a
total mess with all the things I have to think about on a daily basis so I now keep a backlog of everything (work and
personal) that I know needs to be done. At the end of each day I review what I have accomplished, re-prioritize the
backlog, and commit to a new chunk of items for the next day. Note that this is only to deal with day-to-day "stuff",
and not, as you describe, for self-improvement although the result is certainly an improvement on my quality of
life and peace of mind. The inspection/adaptation element comes naturally as part of the review and re-prioritization
process, and I have not (yet) found the need to put aside special times for that.
Scrum is such a simple framework, and its principles can be applied in many different contexts. What I find
interesting is that the resistance to Scrum in organizations is often based on a perception that it is a highly unnatural
way of working. People fear it because it is so different from what they are used to in the work environment.
When I work with organizations I like to guide them towards finding examples of how they actually use many of the
Scrum principles in their daily life already, e.g. making lists, prioritizing important things over non-important ones,
trusting that their husband/wife/kids will make good on their commitments, task-sharing on chores, regular family
meetings, etc. This frees the mind to see that Scrum is actually a very natural way of thinking and operating.
There was an amusing thread on this list about two years ago regarding the use of Scrum to organize family life.
Here is the kick-off post, from Michael Vizdos:
Tobias23
22
Pete Deemer petedeemer@yahoo.com

From: Tobias Mayer tobyanon@yahoo.com; Sent: Monday, July 17, 2006 at 5:15 AM
Subject: Personal Scrum
23
15
Section Two:
Team Space and On-Site vs. Offshore
16
2.1 Bull Pens / Co-location / Open Space (Quiet Working Conditions vs. Common Room)
At Danube, we have a large Bull Pen that houses all team members without barriers. We've definitely seen the
positive effects like spontaneous collaboration and assistance. But I've also noticed people getting distracted and
even annoyed by the enthusiastic discussions of teammates or neighboring teams. We've elected to keep our Bull
Pen because the value added outweighs the minor interruptions, but I wonder what others have concluded.24
________________________________________________________________________
My experience with the disturbance phenomenon has been that different people have different thresholds for
when and how much they need quiet time to solve problems. It is helpful if team members are sensitive to and
respect these individual differences in their teammates.
One technique I have seen work well to indicate someone who needs to concentrate at a given time is the use of
headphones. This says: please don't disturb me, I am concentrating. It also helps block out the noise of distracting
comments and activity from others. For those who find music itself distracting, there is really no reason you have to
play music (no one will know), the visual cue alone may be sufficient.25
________________________________________________________________________
On the one hand I see great value in the common room approach to a team working together I know that the
synergy of a group happens in part because of personal interaction. So I find great value in a process that recognizes
this trait.
However I am finding it difficult to balance this with the concept that knowledge workers need quiet working
conditions to be productive. I think this is common sense. One needs to get into the flow and distractions will
knock you out of flow.26
________________________________________________________________________
For both me and the teams I've coached, the difference is not quiet as such, but whether the noise is related to the
project. On-topic discussions don't seem to interrupt flow in the same way that off-topic ones do. The last team I
was on developed enough of a conviction about this that we would kick the CEO out of the project room if he
started to shoot the breeze with the product manager.
My current favorite trick when I need to have a potentially distracting discussion but don't have alternate space
available is to go for a walking meeting. Three people's about the maximum for this, but it's a good way to have a
chat, reduce stress, and get a little exercise27.
________________________________________________________________________
Having worked in both traditional and open workspaces, I much prefer the latter, and find music a good alternative
to walls.
But note: without walls, it can be very important to help people reduce peripheral *visual* distractions I think that,
if you can, each person (or pair) should have one direction they can turn and not see anyone else (while seated).
This can be done with half-high partitions or filing cabinets, etc. (As soon as you stand up, you see everyone again,
and you can still hear everything). This is more important to some than others, but it's important to be sensitive to
this. As a visual person, this kind of "visual noise" is MUCH more disruptive to me than sound it can totally
wreck my concentration. I guess if you're using XP's "caves and common" then this would apply only in the
"caves". But we used this to achieve a totally "open" feeling workspace while allowing concentration, worked really
well. But it requires a little more available desk real estate to keep it "open" otherwise you are back in cubicle land.
(This was a SteelCase solution, in case anyone is wondering).28
________________________________________________________________________
24
From: Victor Szalvay victor@danubetech.com; Sent: Saturday, September 18, 2004 at 4:31 PM
Michael K. Spayd, COGILITY, LLC
26
From: David A Koontz dakoontz@yahoo.com; Sent: Thursday December 16, 2004 at 11:23 AM
27
From: William Pietri <william@s...>; Sent: Friday December 17, 2004 at 3:22 AM
28
From: "Deb" <deborah@h...>; Sent: Friday December 17, 2004 at 8:41 AM
25
17
My take is, as always, keep a balance, between isolation and constant communication with the group.
Prolonged time in isolation, i.e. with no "real contact" with people, generally pulls people apart. On the other hand,
too much interaction in the Bull Pen can be distracting.
We have had as many as 10 people in the room at any one time, with 1 or 2 people over time, "listening to music" on
and off, but when it is time for everyone to get involved, we ask people to re-join the group. Also, on personal calls
to cell phones or longish "interesting but not-work-related" conversations, most people leave the Bull Pen.
On the other hand, if there is a spontaneous collaboration conceived, we typically have it done at the Bull Pen, with
the option to go to a couple of little conference rooms close by. These rooms have conference phones that are also
used to call remote developers or customers.29
________________________________________________________________________
[Reference to interesting article on a team development room. ED.]
http://www.hello.nl/articles/Asoftwareengineersoffice.html
It alternates people so when looking directly ahead there isn't anyone in front of you.30
29
30
From: Mike Beedle beedlem@e-architects.com; Sent: Friday December 17, 2004 at 6:01 PM
From: todd <todd@p...> Sent: Friday December 17, 2004 at 8:59 AM
18
2.2 Dispersed (Non Co-located) Teams

My company is doing some pretty interesting things ... a community of people that are committed to making the
business successful, but who are part-time and potentially transitory in nature. We will have approximately 6-8
people doing a "normal" full-time equivalent's worth of work.
These folks then are not only geographically dispersed, but chronologically as well. Stand-ups would have to be not
only virtual, but modified to say not yesterday, but last time, next time for instance. Estimating, planning and
tracking all get highly challenged in this environment as well. The closest and best example I could think of would
probably come from the open-source community, but they probably don't have the commercial deadlines that our
business might impose on us.
I'd be curious if anyone has had any practical experience with something somewhat similar in an Agile environment,
and if you could share what worked or didn't for you.31
________________________________________________________________________
One team is local and the other is offshore 11 1/2 hours ahead in time. I wanted to get some feedback from the
Scrum development group as to how to organize such a team. Does "Agile development in the large" cover teams
that are in multiple locations and in distant time zones?
-Ron Wahler32
________________________________________________________________________
Key practices:
1) Lots of unit tests
2) Daily calls at 10 pm or 7 am (or sometimes both)
3) User-level testing of subcomponents as early as possible.
Using 2) you can ensure 1) and 3) get done, and doing 3) helps spot cultural/stylistic issues early and keeps them
from getting embedded all over the code.33
http://www.martinfowler.com/articles/AgileOffshore.html
31
From: "jdmcauliffe2002" jdmcauliffe2002@yahoo.com; Sent: Thursday, September 22, 2005 at 6:05 PM

Subject: Interesting Agile Project Management Challenge
32
From: Ron Wahler
33
From: John Brothers jbwork@undefined.com
19
2.3 On-Site Customer

Scott,
With the Offshore project using Scrum that you have been involved in do you have a local customer representative
(that is a person located in the same place as the people doing the coding)? Is that person from the company funding
the project or from the offshore company? How much responsibility did this person have?
I have been offered a position that would mean I am acting in this particular role. My concern is that as a local
customer representative I would need to be able to make decisions, on the spot and not always delay and get a
response from the person asking for the feature. Any information you could provide about how you have seen this
work would be appreciated.
Thanks,
Kristan34
________________________________________________________________________
I have various scenarios, and always it is customer driven; however in light of your question, no in general I do not
have an advocate on site in all projects. Because then that person becomes the team for want of a better phrase. By
this I mean that the customer site will always go through the same person for all issues, which for me is not a good
place to have a communication bottleneck.
What we do, is use a lot of tools to enable free communication across the teams no matter where they are, this is
actually harder than would first appear.
Now to tackle your concerns, as I stated above you could if not careful end up the bottleneck in communication to
which you have alluded already, it sounds in the role you are talking about you are more of a product manager
<backlog product manager> more than anything else, in this case it could work well if you have very clear and open
communication with the offsite ScrumMaster and team, again I can never stress the importance of real time
communication when working Agile across distance.
In fact I suspect that you like I, will discover that the Agile process, is more a communication aid than anything else,
and its through this communication of project visibility in a near real-time basis that enables Agile projects to react
faster and redefine their targets
So in short, you seem to be in a defined product manger role <typical Scrum> correct me if I am wrong, and your
client may expect you to able to respond immediately with feature requests and issues? If this is the case, it would
be advisable to get the client to agree to a minimal time delay before you can answer, do this by quoting the classic
QA Impact analysis line, i.e.: before a quick response can be given you need to get at least a quick/brief idea of the
impact to the current Sprint/product development. I have met very few companies/clients that will not allow you to
do a quick check on the impact of a new feature.
The only issue then would be how quick you can get feedback from teams on the impact of a change, very rough
estimate as always...
34
On Behalf Of Kristan Vingrys; Sent: Monday, May 23, 2005 at 8:31 AM
Subject: Offshoring with Scrum
20
Sorry this email all over the place; I am typing on train :) please email further questions, and yell at me in CAPS if I
miss the point of the post.
Good luck
Scott Worley35
35
From: Scott Worley worleys@project-inspiration.com; Sent: Monday, May 23, 2005 at 11:23 AM
21
Section Three:
Teamwork and Hierarchy
22
3.1 Application Architecture Across Teams

I was wondering if anyone has any experience or thoughts on how an Application Architect that works across
different teams has been used in a Scrum development environment. We are in a situation where we are thinking
about creating an application architect position in which we hope we can better align the architecture and coding
standards among different teams so that the company begins to make headway into establishing a more standardized
architectures for different applications we host and to be able to create "recyclable" components that can be reused
by any team. Have Application Architects been able to work effectively with different Scrum teams? Seems that
one of the key elements in Scrum is that the TEAM is really empowered to make their own decisions to keep the
project moving along? Does that mean that the Application Architect would really have to be a member of more
than one Scrum team to help keep all of the team's architectures aligned?36
________________________________________________________________________
I believe a good approach would be to have one member (possibly two) of each Scrum team be a designated to be a
member of the Application Architecture team. This team might meet once a week to discuss the architectural goals
and nominate various components of their Scrum team's architecture as being worthy of being promoted to being
part of the overall application architecture. Otherwise, these architects actively participate in their own Scrum's
activities where they actively spread the standards and goal of the Application Architecture to the other members of
their team. Rotating membership in the Application Architecture team might work if you have enough senior staff.
Creating a dedicated Application Architect position is likely to cause a schism and be less effective than leveraging
your current resources and team structure as suggested above.37
________________________________________________________________________
I agree with Steve's comments my teams use a designated architect in each Scrum team with a "chief" Architect
responsible at a department level. All of the component architects work on a team with the chief architect to ensure
that the standards, patterns, and overall architectural concepts are applied appropriately and, when necessary,
challenged if a new paradigm is discovered.38
________________________________________________________________________
I also agree with Steven. Have a "Scrum of Scrums. We have been doing as he suggested for over a year now
(even though we haven't been using Scrum that long) and it has worked quite well.
A risk in having a specified application architect is that you might introduce unproductive conflict to the Scrum
team(s). A Scrum team needs the freedom to do whatever is necessary to meet their Sprint goal. Their overriding
goal is always to provide working software that meets their customers' needs. If a standard architecture and
recyclable components are not valuable to the customer, then building them should not be valuable to the team. If
an Application Architect is there to enforce those standards, he can become an obstacle to the team.
I've been in that architect's position where a team has found a workable solution to a customer problem but I can see
a more abstract solution that would allow it to work for other projects. The team has already completed their
solution and it meets their customer's need, so who is going to take the time to expand that solution? The team has
no incentive to do so, and I don't have the time.
It can also become quickly overwhelming for one application architect to keep different projects aligned. Even with
two or three small teams (<5) there is so much design and code produced so quickly, (because the teams are
empowered to solve their own problems); the Architect can have a difficult time keeping up. If the teams wait for
the Architect's approval he again becomes an obstacle.
36
From: Grant grantj@review.com; Sent: Tuesday, September 28, 2004 at 3:20 PM
Subject: Role of Application Architect on Scrum Teams
37
From: Steven Gordon sagordon@asu.edu; Sent: Tuesday, September 28, 2004 at 3:53 PM
38
From: "JASchiel" james.schiel@siemens.com; Sent: Wednesday, September 29, 2004 at 01:27 AM
23
For us the best way of producing recyclable components and consistent architecture is to have lots of open
communication across the various teams.
We have the "designated architects" meet at least once a week to describe in general what the teams are working on.
This gives us a chance to coordinate dependencies, recognize problems another team has already solved, offer
suggestions, recognize common "design themes", make "core" architectural decisions, etc. It is also common for us
to call in the other team Architects for a half-hour discussion or so whenever we're considering a significant
architectural change. We have no controlling authority, but the best solutions turn into the "standards" because the
solution is carried back to each team in the architects' heads.
Another thing that has helped us is to hold frequent "brown-bag" lunches where the entire development staff is
invited and someone will "show and tell" about some bit of code. This gives the whole staff some idea of what else
has been done on other projects that can be reused, copied, extended or otherwise leveraged.
Another suggestion from Ken Schwaber's book, if this works for you, is to create an "architecture" Scrum team
made up of your very best developers. They would do a Sprint or two to establish the core shared pieces and
standard architecture. Everyone on that architecture team will gain a large amount of tacit knowledge about the
standard architecture. Then split up the members of that team into the other teams doing the regular day-to-day
work. This should promote lots of inter-team communication when issues about the standard architecture come up.
This has been my experience. I hope the information is useful to you.39
39
From: Mike Schenk mike_schenk@yahoo.com; Sent: Wednesday, September 29, 2004 at 04:48 AM
24
3.2 Self-Organizing Teams

Paul, Alejandro
Self-organizing and self-directing (self-managed) are different. A friend of mine worked for a company that went to
self-directed work teams, eliminating project managers. Now the team got to do all the paperwork HR, reporting,
budgets, etc. No more time to actually develop software. To me, self-organizing teams are led (and managed) by a
designated project manager, a technical lead, a ScrumMaster, etc. It's the style of leadership that is different one
I've called Leadership-Collaboration rather than Command-Control management. There is just too much evidence
that good leadership and management makes a huge difference to success. These leaders are team leaders, not
project administrators (although they do take some of this burden off the teams). The idea that you can put a
random group of people together and that a "leader" will emerge just isn't borne out by experience. In fact, even
Orsburn, "Self-Directed Work Teams (1990)," says it takes 2-3 years for self-directed teams to jell. Who has that
long?
Self-organizing teams have a lot of freedom, are empowered to make many decisions, and manage their own work
to a great extent. They also have a responsibility and accountability to produce, and they have to be self-disciplined.
Self-organized doesn't mean dis-organized. It means a self-disciplined team and a Leadership-Collaboration style
leader/manager working hand-in-hand.
Cheers,
Jim40
40
From: Jim Highsmith jim@jimhighsmith.com; Sent: Friday, June 3, 2005 at 4:28 PM

Subject: RE: Agile and Self Managed Work Teams
25
3.3 ScrumMaster: Elected From Team

Hi,
I'm a project manager at a videogame studio looking to use Scrum for my next big project. However I really want to
avoid myself being a bottleneck by being the ScrumMaster, and think it would take the team a long time to get used
to me NOT making the decisions in their meetings.
Now I've seen a couple of papers mention the option of allowing the Scrums to elect one of their members as
ScrumMaster for each Sprint. While I completely embrace this on the team empowerment front, the project is of
utmost importance to the company, and I'm wondering if I'd be introducing a whole new layer of risk by allowing
any team member to be elected as SM and then not be able to cope with the role.
Does anyone else have any experience of using self-directed teams, and is there any advice that can be offered for
ways to try and reduce the possible risk? I could of course nominate the SMs per Scrum myself, but then am I not
breaking the ownership of the Scrum teams and risking their buy-in?
Thanks in advance for any advice on this,
Chris.41
41
From: "another_chriss" another_chriss@yahoo.co.uk; Sent: Monday, April 25, 2005 at 12:07 AM

Subject: Advice for Using Self-Directed Teams
26
3.4 ScrumMaster: Team Member or Coach

Tobias Mayer [tobyanon@yahoo.com] wrote:
> 1. Should the ScrumMaster be a member of the team, i.e. one of the developers or should he/she be separate from
the team, /only/ concerned with removing obstacles and liaising with the product owner?
In our experience, Scrum works best when the ScrumMaster is a full-time member of the team for very many
reasons:
* Commitment to solve team issues
* Focus in the task at hand
* Constant but not intrusive coaching
* Realization
* Provide constant communication with external teams: Systems, Business, Testing (if it exists, as
in integration of many teams)
* Help with technical tasks, but typically:
Testing
Documentation
Integration and sometimes even
Development
Remember the "ScrumMaster" is insurance for the team insurance that things will get done, that the team will selforganize in a productive way that the right technical decisions have been made, etc. (In many cases the
ScrumMaster and the Technical Lead can be the same person, but that in my opinion is "optional".)
When the ScrumMaster is not a full-time member of the team, she typically becomes distant to the team, a "Town
Crier" or sorts that simply takes "news" and gives "news". (In this case the ScrumMaster becomes almost a
traditional project manager...).
> If the latter is true, is this always a full time role or can a ScrumMaster work on multiple projects at one time,
even if they are completely > unrelated projects?
In my opinion, working for many projects is *very dangerous*, all of the members of a Scrum team *must be
focused* on the realization of the team's goals FOCUS is one of the very basic premises of Scrum.
________________________________________________________________________
> 1. Should the ScrumMaster be a member of the team, i.e. one of the developers or should he/she be separate from
the team, /only/ concerned with removing obstacles and liaising with the product owner? If the latter is true, is this
always a full time role or can a ScrumMaster work on multiple projects at one time, even if they are completely
unrelated projects?
I recommend that the ScrumMaster not be part of the Development Team or Product Owner roles. It's possible an
individual could maintain the balance needed to be both a participant and a facilitator/coach, but this can be hard
especially if it's one of your first Scrum projects. It's kind of like a player-coach in sports some can pull it off, but
not very many. There is a lot of facilitation and coaching needed for both the Product Owner as well as the
Development Team.
You speak of the ScrumMaster as if he is a liaison between the Development Team and the Product Owner. This is
not the case these two roles work directly together. In fact, all three roles work closely together as three separate
but interlocking roles.
I have a client now with a ScrumMaster successfully timesharing between two teams, and we think he could perhaps
handle a third. But there are some days where he is stretched pretty thin, and not immediately available if a team
needs assistance. I think a ScrumMaster needs a certain level of expertise and experience before they can learn how
27
to be efficient enough to juggle several teams, but I think it's possible. The teams would also have to schedule their
planning, review, and daily Scrum meetings in a way to allow the ScrumMaster to attend all of them.42
________________________________________________________________________
It really depends on the personality of the ScrumMaster. I think it works best when the ScrumMaster has few or no
specific deliverables within a Sprint. If the ScrumMaster does, it is usually best that they not be "critical path" type
tasks. That is, I don't want the ScrumMaster taking the hardest or longest to complete tasks and then spending a lot
of time on removing impediments (which comes first).
--Mike Cohn43
________________________________________________________________________
There is no reason that the ScrumMaster could or couldn't be a member of the team. If the ScrumMaster is a team
member, then he needs to very carefully separate out the two functions and avoid being "in charge" of the team.44
________________________________________________________________________
My 2 cents about a ScrumMaster taking on Teamwork:
I've acted as a developer and a SM on the same team on various occasions. It appeared as if it "worked," but over
the last few years, after learning very much about the role of a SM, I have come to regret those occasions, as I have
realized:
-That any time I spent doing any "Team" activities (acting as a Team member/developing/etc) was time NOT spent
creating an environment of success for the team or doing other important SM activities (championing process to
questioning stakeholders, other coaching, etc. etc.)
-That any work I did to "help" the team may have been a missed opportunity to learn and solve problems on its own
(e.g., sure I was able to automate some builds and deployments more quickly or help knock out some stories, but
wouldn't the team have benefited from the learning?)
-That any work I did may have detracted (though perhaps only slightly) from the Team's ability to accurately
determine what it was capable of implementing in a particular Iteration
I now consciously try as hard as possible to not do any development or other "Team" work- even if I have a
competency in an area that the team doesn't- in this case I'll advise or recommend or guide team members if needed.
Unless the organization I am working with is completely evolved and embodies our principles throughout (haven't
been there yet), and all is happy and at peace (dogs and cats playing together etc.), there is likely something that
likely can be done by the SM to improve things that would be a better effort than signing up for Team tasks.
DeMarco's wonderful book "Slack" has another view of taking on work as a manager also that I believe is
consistent.
George45
42
From: Paul Hodgetts phodgetts@Agilelogic.com; Sent: Sunday, January 9, 2005 at 12:50 AM

From: Mike Cohn mike@mountaingoatsoftware.com
44
From: David A Barrett dave.barrett@lawpro.ca; Sent: Monday, January 10, 2005 11:46 AM
45
From: George Schlitz gjschlitz@comcast.net; Sent: Friday, July 14, 2006 at 9:11 PM
43
28
3.5 ScrumMaster: Communication

Bentley has the advantage of highly technical Product Owners, which facilitates communication between the
Product Owner and the development team.
The goal of bringing 14 teams up to speed at the same time is ambitious. Of necessity, the teams will get the "What
to do". But with minimal training, the "Why" is missing. Also, the "What might be close but not exactly on the
mark. ScrumMasters may find themselves answering a lot of questions and fighting a lot of little fires. If so,
consider an ad-hoc mini-retrospective that might get to issues you don't want to let go the entire Sprint.
When we take away technical decisions from the ScrumMasters they can think that they don't have enough to do
(initially). If you have this situation, I think it is a mistake to let the ScrumMasters take on technical tasks as part of
the project team. (I have more of a fear of this in Bentley's case because everyone is so technical to begin with.)
They could use any free time to do some reading on Agile or plan to spend more time discussing obstacles and
opportunities with other ScrumMasters.
With lots of rookie ScrumMasters, there will be some variability in their performance. Management should sit in on
Scrums and do a lot of observation of teams and ScrumMasters to: 1) identify issues before they become problems,
and; 2) demonstrate their support for the new process.
Bhupinder identified the benefit of sharing successes. A frequent gathering of ScrumMasters might be one forum to
facilitate this.
A weekly Scrum of Scrums might be too infrequent. Better to over-communicate at first. I recommend that you
start out with a daily Scrum of Scrums and decrease that if it proves to be overkill.
Technical input into the product seems to be a hallmark of Bentley. You may need to emphasize that this will
continue in the future and show the technical teams how they will be able to accomplish this. The technical teams
don't want to feel disenfranchised. One team expressed this and therefore showed us the problem. But they are
probably not the only people to feel this way so the problem has to be solved for a wider audience.
I will be interested to see how ScrumMasters deal with the communication issues with remote offices.
Bentley Systems, September, 2004
29
3.6 Business Analysts and Scrum

Being a Business Analyst, I have been hunting around the web and in bookstores as to how a Business Analyst team
would fit into an IT organization practicing Scrum.
We have an IT organization that consists of teams of Business Analysts, Developers, QA folks, Project Managers
and Business users.
I understand that Scrum recommends that the same person wear multiple hats, but that is really not possible here.
I haven't heard this specific recommendation in relation to Scrum. At a very, very high level: Scrum wraps any
development process with several Agile project planning/tracking/management practices (the primary rule is that the
team cannot be interrupted during the Sprint). The details of the development process are essentially a black
box as far as Scrum is concerned (which would include the specific allocation of roles/people on the team).
In the past I have worked through an organization where we implemented XP successfully and integrated BA and
QA by putting BA 1 Iteration ahead of dev...
I have also seen this strategy work successfully in certain situations where:
a) The requirements were uncertain, because the business process were being re-engineered in the same time
frame that the system was being developed. In these cases, the 'analyst' worked with the business experts to define
the business processes a few steps ahead of the system development.
b) The requirements were complex, the development team was not familiar with the domain, and/or the customer
could not explain the requirements clearly, succinctly, etc. In these cases, the 'analyst' kept one Sprint ahead of the
developers so that they could pre-digest the upcoming requirements into a clear, logical form so that the developers
didn't have to come to a standstill in order to understand the new requirements. The developers would use these
'pre-digested' requirements as a starting point, and would continue to have face-to-face conversations with the
customer and/or the analyst in the course of the Sprint to get the finer grained details worked out.
and QA one Iteration behind Dev...
This makes sense if the QA people are doing incremental hands-on testing (e.g. exploratory testing, usability testing,
integration testing, performance/stress testing, etc) against the functionality integrated and released at the end of the
Iteration. It's important to remember that the test-first development practice of XP puts a lot of the testing
before/during development that is 'traditionally' left for after development.
...But within Scrum everyone stays in the same Sprint. The BA, Dev and QA folks.
Once again, I haven't heard this specific recommendation in relation to Scrum. Scrum's main restriction is that the
scope of a Sprint is fixed, and should not change part way through (as a way to reduce churn and keep the team
focused). That doesn't necessarily mean that everyone has to work on the same thing during the Sprint. So I believe
it is entirely reasonable if the situation requires an "analyst" to pre-digest upcoming work to make the next Sprint
proceed more efficiently.
So how could all three groups work within the same PB simultaneously without someone having a good amount of
downtime? Since you really cannot develop before analysis and design is complete, and since you cannot QA
before dev is complete.
The XP approach of stories/acceptance tests/face-face conversations all occurring in the course of an Iteration works
well in an ideal situation where:
a) The developers already have a strong understanding of the domain, or the requirements are simple enough that
they could understand them quickly
b) And the customer can articulate their requirements effectively
30
If your situation is not ideal, then adding an "analyst", and/or pipelining the analysis and development work may be
an appropriate solution.
Jennitta46
________________________________________________________________________
How is the knowledge acquired/generated by the team that analyzed requirements in Sprint A to be communicated
to the team that implements those requirements in Sprint B?
If that knowledge is to be communication is via heavy documentation then the approach is not in the spirit of XP or
Scrum, and much of the agility one gains by doing XP or Scrum will be lost. Much of the knowledge gained by
team A will have to be relearned/reinvented by team B, and given the different skill sets, team A is likely to want to
disown what team B produces.
The idea behind these methodologies is for one group of people to learn, implement, and get feedback in a short
time frame on a few requirements. Spreading the learning for the same requirements across multiple groups of
people destroys what makes the methodologies Agile and effective.
If the requirements are too complex for a group of developers to figure out and implement in one Iteration, then
reduce the number of requirements per Iteration and/or add a few BAs and SMEs to the team. A separate team of
BAs and SMEs will only muddle things.
Steven Gordon47
http://sf.asu.edu/
________________________________________________________________________
A customer story is a very short paragraph (not even as detailed as an "essential use case") identifying a requirement
or feature. The customer prioritizes these short stories. The team only digs into the details of a story when its
priority causes it to be scheduled for the current Sprint/Iteration. The people who will be implementing that story
have an extended discussion with the customer at that time to come to an understanding of its details. (Discussing
the details before implementation time is pointless, because the details are likely to change in light of the customer's
experience with what as been implemented so far, as well as all the factors that cause changes in requirements and
how they are understood).
There is absolutely no problem with BAs and/or SMEs participating in that conversation with the customer. There
is a big problem with the BAs and/or SMEs having that conversation INSTEAD of the developers, and then
providing a written specification of some sort to the developers based on that conversation.
The in-between case of having the BA have the conversation with the developer instead of the customer is not
optimal, but can work when there is no better alternative. But, that conversation is still a 2-way dialogue about what
the requirement really means, not the BA dictating to the developers what to implement. It should not take a full
Iteration of work by a team of BAs to support being able to have such a conversation with the developers.48
________________________________________________________________________
Scrum is pretty adamant that you start the Sprint "with nothing" and you end it with a potentially shippable product
increment. This means you start with a tiny bit of understanding about what a product backlog item means and you
end with shippable software.
Regardless of your environment that should be considered the ideal. But, we can't always achieve the ideal. I've
occasionally had teams that need to do some analysis "a Sprint ahead" of the team. This is OK as long as you
remind yourself often that:
46
From: Jennitta Andrea jennitta_andrea@transcanada.com; Sent: Tuesday, November 9, 2004 at 9:46 AM

Subject: Re: Scrum and Business Analysts
47
From: Steven Gordon sagordon@asu.edu; Sent: Tuesday, November 9, 2004 at 1:28 PM
48
From: Steven Gordon sagordon@asu.edu; Sent: Tuesday, November 9, 2004 at 2:24 PM
31
a) You are deviating from the ideal, you've selected to do something that works but it would be better if you could
get closer to the ideal
b) You try to minimize the amount you do ahead and how far ahead you do it.
(All the same with "behind" as appropriate)
Whatever the analysts feel the need to produce upfront should be kept as lightweight as possible. We want to view
their work as inventory and it could be wasted inventory if the feature isn't prioritized into the Sprint.
I can't think of any real circumstance in which I would have significant testing occurring AFTER a Sprint. I've had
some teams where we do things like usability testing (bringing users into a usability lab for observation) every 3rd
Sprint or so but it's still done in a Sprint. It's just not something needed every Sprint though. I'd push back hard on
testers wanting to work behind. Usually when they are doing that they are trying to optimize the test process at the
expense of the overall process. Imagine a sandwich store with 13 order-takers and 1 sandwich maker. Order-taking
will be optimized Never a wait to place your order" will be in the ads. But imagine the wait for the sandwich to
be made. You want a process that is optimized across the range of activities. This means that some processes will
look inefficient. It's very "inefficient" (when measured locally) to write tests first but it can help optimize the entire
process.
--Mike Cohn49
________________________________________________________________________
Much of the information can often be conveyed during a Sprint planning meeting. If there's more to be conveyed
(there almost always will be on some stories) then the relevant programmers, testers, etc. all talk to the customer. If
there's that much talking going on (e.g., this is a complicated requirement) the customer hopefully starts to write
down an example (see www.exampler.com) or a test demonstrating how the system should behave. The best
becomes the most powerful way of capturing the communication for later use.
--Mike Cohn50
49
50
From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Tuesday, November 9, 2004 at 8:19 PM

From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Tuesday, November 9, 2004 at 8:24 PM
32
3.7 Is the Product Owner a Pig or a Chicken?

> 2. Is the Product Owner a Pig or a Chicken?
In my opinion, it is neither. In Scrum, the Product Owner is the person that makes the final decisions about the
content of a Sprint, and it is typically a decision-maker that is not available at all times as a good pig should be.
And it is neither a chicken a person that is not committed to the goals of the team.
There is another role, the Customer, that needs to be introduced, imo. The Customer, is or are representatives of the
business that typically work for or with the Product Owner. These representatives are pigs i.e. they are committed to
the project on a daily basis to clarify requirements, and are capable of giving feedback on a day-to-day basis on the
functionality of the daily builds in terms of testing and tactical decision-making.51
________________________________________________________________________
>It seems to me that the product owner is certainly committed, but I do not see a place for the product owner to
speak in the daily Scrums, it seems that he/she should just listen.
The Product Owner is brought in typically when major decisions are made regarding a Sprint. For example, to
answer questions about compromises such as: "Can we live without the Complaints Workflow for the next release?"
We call these meetings "Reprioritization Meetings", and typically there are one or two of these meetings at most per
Sprint.
For most other tactical decisions, other representatives of the Customer are usually sufficient.
In Scrum, it is *the worst-case scenario* to not interact with the Customer (either the business representatives or the
Product Owner) only through the Sprint Planning Meeting and the Sprint Review Meeting.52
________________________________________________________________________
I consider the Product Owner to "have skin in the game" for a Sprint, and thus be a "pig" (I dislike that term :-P).
They will have different tasks during a Sprint, mostly focused on building and accepting backlog items, but they
must complete work for Sprints to move forward. They will report on their tasks just like the members of the
Development Team do.53
________________________________________________________________________
The ideal product owner is definitely a pig. The product owner should be saying things like, "Yesterday I checked
with marketing on ... and it's what we thought so you can go ahead and. The product owner should also have lots
of tasks associated with writing (specifying at least) acceptance tests for the work of the Sprint. Product Owners
should be close to the team if not in their same space availability is more key than location. The Product Owner
and ScrumMaster meet whenever they need to. I typically tell them that they should be in sync before each planning
meeting and should also have a good feel for what will likely be stated as high priority by other
stakeholders/customers. Neither should ever surprise the other.
--Mike Cohn54
________________________________________________________________________
51
From: Tobias Mayer tobyanon@yahoo.com

Subject: Pigs vs. Chickens
52
From: Mike Beedle beedlem@e-architects.com; Sent: Sunday, January 9, 2005 at 1:01 AM
53
From: Paul Hodgetts phodgetts@Agilelogic.com
54
33
The Product Owner is a chicken. Sorry Hubert, but I have to disagree with you here. Yes, the Product Owner is
committed to the outcome of the work, but he's not a part of the work. Within the Scrum structure, the Product
Owner has a single role: To maintain the Product Backlog and to prioritize the PB items. Remember that the team is
jointly responsible for completing the Sprint Backlog. The Sprint Backlog isn't carved up into a bunch of individual
commitments for each team member, so every team member is expected to become involved in any aspect of the
Sprint backlog that requires attention when necessary. Your most senior programmer may spend three days stuffing
envelopes if that is what is needed, and if the team decides that is the best use of his time.
I divide the Scrum world into two kinds of people: Team Members and Resources. A team member is someone
described above, who is fully committed to all of the objectives in the Sprint backlog and who will work in any
capacity required (providing that he has the skills) by the team to achieve those objectives. A resource is someone
who is available to a specific task, or whose skills are highly specific or whose available time for the project is
extremely limited. The team decides how best to use that resource, and the resource usually wouldn't attend a
Scrum as a pig. What usually happens here is that a team member becomes responsible for watching over the
resource, and reporting that person's progress and issues to the team in the daily Scrum. If you have someone who is
part-time on the project, the decision over whether or not they are a team member depends on how much time you
have them for. If you have enough of their time for them to attend the Sprint Planning meeting and all of the Daily
Scrums, then they're probably going to work best as a team member. If you only have them for 1 day a week, then
they'd probably best utilized as a resource.
Dave Barrett55
________________________________________________________________________
I disagree. Pigs are those who have commitments, or whose bacon is on the line, during a Sprint. That applies to
the Product Owner who is responsible for specifying (and writing if possible) tests that indicate if each backlog item
meets her expectations. While the team can self-organize and influence the amount of effort needed by the product
owner to do this, the product owner must do some of it as no one can express the product owner's acceptance criteria
except the product owner.
--Mike Cohn56
________________________________________________________________________
I believe having a Product Owner as a pig is ideal. If this is not an ideal situation because of circumstance, the
ScrumMaster takes some of the burden of Product Owner. This can happen when the Product Owner cannot be
involved as much as we would like and delegates much of the role to others. At this point, the Product Owner
becomes a chicken. This causes for a lot more work from the team, which is why it is better when the Product
Owner is a pig.
As a pig, the best of all is when the Product Owner is part of the Daily Scrum!
Brent57
________________________________________________________________________
The "chickens and pigs rule", is about who talks at the Daily Scrum... not who is committed to success of the
project, or who has "skin in the game".
Chickens are only involved in the process they provide the eggs in the "eggs and bacon" breakfast. For example,
there could be a system administrator there to know what new users to add, or a configuration management guy, or a
DBA, or a senior VP (wanting to know where things are), etc.
55
From: Dave Barrett, Lawyers' Professional Indemnity Company

57
From: Brent Barton bbarton@solutionsiq.com; Sent: Monday, January 10, 2005 at 9:05 AM
56
34
Pigs are committed to deliver the (software) through and typically have something to show for in the "Daily Build"
(even if they are documents), and therefore are typically developers (in the larger sense more than programming)
they provide the bacon in the "eggs and bacon" breakfast.
This rule goes into effect so that people only "involved" with the project take over the Daily Scrums. For example,
the CIO, the VPs, or the Directors don't take over the meeting and start thanking people, telling them how great they
are, or start threatening with contract fines, or panicking, etc.
This is why the "Product Owner" does not typically talk at the Daily Scrum; therefore, most Product Owners are
chickens at the Daily Scrums. And yes of course he is committed to the project and he has "skin in the game" but
that's not how we use the "chickens and pigs rule".
On the other hand, there might be business people working on a day-to-day basis as part of the team (or with the
team), that are responsible for delivering the solution those people are of course pigs.... but they are typically not
the Product Owners (although it is possible they might be involved at that level), they are simply "On-Site
Customer".58
________________________________________________________________________
Well, you're the expert. But now I'm confused. AFAIK "On-Site Customer" isn't a Scrum term. I thought that the
Product Owner was the one who defines the Sprint Goal, in its general form and its detailed form. Yet they aren't
present with the team?
Ron Jeffries59
________________________________________________________________________
Ron,
You are right, in Scrum we don't have an "On-Site Customer", we simply have a "Customer" ;-)
The Product Owner helps define the Sprint Goal and content, but of course the team determines how much can be
done and how to deliver it.
It is ideal that the Product Owner is available all the time during the Daily Scrums and during the day, but that is
typically not possible, nor is it required in Scrum; instead, most of the time we have a committed Customer
representative that helps the team, full-time or part-time, in testing the deliverables and understanding the
requirements.
The absolute "worst case scenario" is when neither the Product Owner nor a Customer representative are available
during the Sprint. Then all the interaction with them happens at the Sprint Planning and Sprint Review meetings.
- Mike60
________________________________________________________________________
Given that the Product Owner is establishing acceptance criteria for the product backlog items, the product owner is
undoubtedly a pig (that is, "is committed") and should most definitely talk in the meeting. If that were not the case
it would lead to a pathology such as having the product owner telling a tester prior to the meeting "speak up if these
acceptance criteria are not being met or if others are" and then having a tester become the mouthpiece of the product
owner. If I were a Product Owner and the team told me "you can't talk during our meetings" I would find a new
team-that day. Agile (and Scrum) teams should value communication-in all its forms and in all ways that help.
Telling the CEO he can't come interrupt a meeting with his questions is a good idea; telling the product owner the
same is wrong.
58
From: Mike Beedle beedlem@e-architects.com; Sent: Monday, January 10, 2005 at 1:22:30 PM
From: Ron Jeffries ronjeffries@Xprogramming.com
60
From: Mike Beedle beedlem@e-architects.com
59
35
I might have been able to believe the "product owner is a chicken" argument in the old days before Scrum teams
started seeing the value of acceptance-test-driven development. However, many Scrum teams have been shifting in
that direction and having Product Owners come into a Sprint with known, high-level conditions of satisfaction
(COS) identified for each or many product backlog items selected for the Sprint. During the Sprint the product
owner (in collaboration with others, esp. testers) refines and automates those high-level COS into more specific
ones. These become the actual tests. This means the Product Owner has deliverables. The Product Owner has
always been committed. The Product Owner speaks in the Daily Scrum. That simple change of mindset eliminates
this entire class of problems.
--Mike61
________________________________________________________________________
Yes, fully agree with Mike AS LONG AS the product owner has committed with the team to what will be
demonstrated at the Sprint Review. Without the commitment, the Product Owner remains a highly interested but not
committed chicken,
Ken62
61
62
From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Wednesday, April 6, 2005 at 9:09 AM

From: Ken Schwaber ken.schwaber@verizon.net; Sent: Wednesday, April 6, 2005 at 9:50:12 AM
36
3.8 Interaction During Sprint

I understand that the customer should not talk in the stand-up meetings, but as a customer I sometimes find this is
not practical.
When developers are starting to talk about an issue and are off track I feel that I should be able to speak up and
correct them. Or if they are discussing a problem and I have a potential solution by changing the requirement
slightly, I also think I should speak up or in some cases I have some information about how the feature is going to be
used which will help the issue.
If as a customer I cannot speak in a stand-up meeting and must wait until the end of an Iteration before I can interact
with the team, that seems wrong and not very Agile.
What is the best way to deal with this? Sometimes I keep quiet in the meeting and at the end seek out the people
involved in a particular task so I can discuss the issue further. Is this how it should be handled, or should I just
speak during the stand-up meeting but keep any chatter short and relevant to the current topics being discussed?
Regards,
Kristan63
________________________________________________________________________
As ScrumMaster, I pay close attention to the chickens in our meetings, as well as to the pigs. If a chicken, esp. the
PO makes eye contact with me or raises his/her hand, I know that there is an issue to talk about after all the pigs
share (and we always get thru under 15 minutes).
I'll point out that the chicken has some valuable information as soon as the last update is complete, or, if the team is
really tightly integrated and comfortable, the chicken could very well "cluck" quickly and say that they have some
pertinent info to share at the end. We also have an alias, so if information needs to be shared that would benefit the
team, the chicken can mail the team the info if appropriate to be shared in that way or call for a separate meeting.
I think it is important to allow the momentum to continue and not interrupt in the standup, and also important that
the team is not operating under incorrect information. I think your solution is perfect, seeking out the right people to
discuss after, and that may drive Iteration as long as it is shared in the next meeting or communicated widely.64
________________________________________________________________________
I would have thought the customer should be constantly interacting with team members throughout the Sprint, what
I am not sure of is how. What is the protocol, if the standup meeting is not a good time, then when is?
As I said, during a Sprint the team is taboo. You do not even go near it. The Planning Meeting and the Sprint
Review are the two days where the Product Owner should interact heavily with the team. The rest of the time you
will leave the team, alone unless the team approaches the Product Owner. This will happen most likely when:
a) There is too much work in the Sprint left and they cannot deliver, asking the Product Owner to drop some items
from the Sprint backlog.
b) There is too much time left, asking the Product Owner to pull some more items from the backlog to the Sprint
backlog.65
________________________________________________________________________
I'd add c) There is not enough information about a backlog item on in what is really wanted, and the team wants
elaboration.
63
From: Kristan Vingrys kvingrys@agentissoftware.com

Subject: Pigs vs. Chickens
64
From: Traci Boyle traci@yahoo-inc.com
65
From: David H.
37
Product Owner is the person with the most information about the items on the backlog. It is usually not possible and
not sensible to document/communicate all the functionality of the backlog items in great detail during the Sprint
Planning Meeting from the Product Owner to the Team.
Therefore most common way of interaction in our organization between the Product Owner and the team is when
the Team/Team Members ask for more information about a certain feature that is being implemented during the
Sprint. I think it is a vital part of Agile methodologies (including Scrum). I agree with you that the initiator should
be the Team, not the Product Owner. The Team knows (at least they should!) when they do not have enough
information about the specific details of a backlog item.
Regards,
Jukka66
66
From: Jukka Lindstrm jslindst@reaktor-i.com
38
3.9 Retrospectives: Who Should Facilitate

I've seen teams taught that the ScrumMaster should facilitate the team retrospective. I don't find this as effective as
having a neutral facilitator (someone outside of the team), at least for the first few Sprints and would like to get your
thoughts on this.
My thinking is that you should have someone who is outside of the team for the following reasons:
1. The facilitator won't bias the opinions given out by the group as much if they are outside of the team.
2. The ScrumMaster has valuable feedback that may be lost if they are not allowed time to give their opinions during
the Retrospective.
3. The team may have problems with the ScrumMaster themselves and not feel free to give feedback if the SM is
running the retrospective.
I've been getting someone experienced in running retrospectives lead the first one for the team, then training all the
ScrumMasters on multiple teams to help each other. They buddy up and go to each other's retrospectives. This had
the double advantage of keeping the facilitator neutral, allowing SM's to learn from other's teams retrospectives, and
providing support for the SM group which is very valuable when you are scaling through a large organization.
~Gabrielle Benefield67
________________________________________________________________________
I agree on the 'improvements' focus on a retrospective, and I'm glad you bought it up Diana. It's all too easy to have
teams vent (some people just like this as their general modus operandi as well ;).
Things I've seen work to ensure the items are worked on are:
1. Putting the improvement suggestions onto the backlog for the next Sprint.
2. Putting up the improvement suggestions on a large piece of paper and posting these in a team room so they are
visible.
3. One I just heard about today, is the team went through the last set of improvements and added happy faces for the
things they resolved and sad faces for the things they still need to work on. They then posted this back on the wall.
Are there any other tricks for making progress on the items out there?
Gabby68
67
From: "gabby_robertson" gabby_robertson@yahoo.com; Sent: Monday, May 16, 2005 at 5:26 PM

Subject: Who should Facilitate the Retrospective?
68
From: "gabby_robertson" gabby_robertson@yahoo.com; Sent: Monday, May 16, 2005 at 8:25 PM
39
3.10 Sprint Review: Stakeholders Role

One problem I see in organizations trying to become Agile is folks getting together for Iteration demos, and the
stakeholders not really quite sure what they are supposed to do. They aren't used to seeing subsets of features and
don't quite know how to, or that they are supposed to, give feedback.
Does anyone have any facilitation tricks (lists of questions, etc.) that they use at demos to get folks giving the proper
feedback?
Ken DeLong69
________________________________________________________________________
Ken, we've started providing short surveys for our customers that ask questions like:
* How closely did our demonstration match what you had hoped to see?
* How easy has the development team been to work with?
* Are there requirements (new ones or ones we missed) that you would like to discuss?
When handed out at the beginning of the review, the stakeholders tend to read them, which then causes them to
think about how to answer the questions during the course of the demo.
You have to be careful with this approach (too many questions takes attention away from the demo), but it can be
successful in both focusing the stakeholders and getting feedback that can be used to evaluate the success of the
Sprint and, across Sprints, the team.
Of course, it also helps to communicate what you want from the stakeholders at the beginning of the meeting and (if
possible) when the invitation to the review is sent/spoken to the stakeholders.70
________________________________________________________________________
If you begin the Sprint with a specific set of requirements (this is an advantage of TDD) then you show and tell at
the end. Here is what you said you wanted; here is what it does. Then you show them how to do it and let them
loose. If they can't break it, then have them sign off on it. (I mean that literally.)
Michael F. Dwyer71
________________________________________________________________________
Hi folks,
Mike Dwyer mike.dwyer1@comcast.net wrote:
> If you begin the Sprint with a specific set of requirements (this is an advantage of TDD) then you show and tell at
the end. Here is what you said you wanted, here is what it does. Then you show them how to do it and let them
loose. If they can't break it, then have them sign off on it. (I mean that literally.)
This is how we do it: We create a list of assertions for each backlog item. The assertions may determine a specific
level of availability or just a feature, which has to be implemented. After the Sprint review where we discuss the
results and get a general overview our teams take their product owner and check the assertions one by one.
Each assertion has to be proven by a range of successful tests. These may be load tests if there was an availability
question. We use acceptance tests for actual functionality, too. The product owner signs the assertion checklist and
we're through it.
69
From: Ken DeLong ken.delong@valtech.com; Sent: Tuesday, February 8, 2005 at 5:55 PM

Subject: Facilitating Iteration Demos
70
From: Schiel James SHS Malvern james.schiel@siemens.com; Sent: Tuesday, February 8, 2005 at 7:28 PM
71
From: Mike Dwyer mike.dwyer1@comcast.net; Sent: Wednesday, February 9, 2005 at 12:28 AM
40
Of course, as we are gathering more and more assertions, the product owner won't look on every detail. We
accomplish this through frameworks that put all tests and other checks together and display them on a common
dashboard. Check out CruiseControl for that kind of stuff.
HTH
Andreas Schliep72
Software Factory
WEB.DE AG
72
From: Andreas Schliep andreas.schliep@web.de; Sent: Wednesday, February 9, 2005 at 7:51 AM
41
3.11 Team Members

I've been involved in a fair number of passionate debates about who is and isn't part of The Team, who's a pig and
who's a chicken, etc. My observation is these debates have a rapidly diminishing rate of return.
I've noticed that a healthy Scrum organization (not just team) forms multiple affinity groups around the work
products being produced, who's working on what, who needs to know about what, who needs to collaborate with
whom, etc.
As Dave points out, Scrum by the book emphasizes the affinity group that is focused on the potentially shippable
increment of product that is emitted from the current Sprint, and calls that The Team. This group tends to be
focusing on the most concrete construction type of tasks, with a high level of immediacy to the completion of them,
and tends to have quite a bit of collaboration going on among themselves.
If we look at, say, a Business Systems Analyst that is working on helping to define and write some backlog items for
the next Sprint, they too are performing tasks necessary to complete product, and they too are committed to the
product. The tasks are a bit more abstract, of the visioning variety, and may not be targeted at product delivered in
this Sprint, so they don't have the same immediacy. They may collaborate very closely with the Product Owner and
perhaps QA if defining acceptance criteria, but not as closely with the folks working on the construction tasks.
However, there is still some affinity between the two groups. As a programmer working on construction tasks for
this Sprint, I still have common interest in what's going on with the BSA and the requirements work, both as a heads
up to my future work and for the sake of knowing the entire project's status.
The bulk of the synchronization in the daily Scrum is for the core affinity group. But in the healthy teams I've
coached, they develop some sort of mechanism for synchronizing with the weaker affinity groups as well. Some
even include them in the daily Scrum activities, perhaps not every day.
So I don't view being part of The Team or not as so black and white, nor constant. I tend to err on the side of
inclusion, with the intent of encouraging collaboration and visibility. I've noticed that most teams are pretty good at
self-adjusting the involvement level of people to match their affinity levels. Although some rules about who's part
of The Team may be useful to a new team so they can instead focus on more pressing issues, it seems to me the
question becomes more and more irrelevant as a team matures.
Paul73
CEO, Coach, Trainer, Consultant: Agile Logic www.Agilelogic.com
73
From: Paul Hodgetts phodgetts@Agilelogic.com; Sent: Friday, March 18, 2005 at 6:11 PM
42
3.12 Performance Reviews

Tobias,
When I've have one or more team members whose performance is also measured by someone external to the team,
I've sought out these external managers with the aim to create a "win/win" for both the manager and the person
being evaluated. What are the objectives of the external manager with respect to the person being evaluated and
how do these objectives fit within the environment we are trying to cultivate? One of the ScrumMaster's jobs is to
create a "safe" environment for the team, where the team members can try out new things without fear that they will
be adversely impacted when they are evaluated by their management. I've found that getting these managers to
express their support for what the team is doing in front of the team has tremendous therapeutic effect.
If you can't create the win/win, the individual, the team, and the project will fail, and it's probably best to move the
person off the team. Bottom line find a way to make it work for everyone.
To your question about manipulation, any external manipulation should surface in the daily Scrum. The
ScrumMaster is responsible for exposing and confronting these external influences real-time. Seek agreement with
these external managers upfront and continually assess what is really happening. Make sure everyone "walks the
talk."
Jim74
________________________________________________________________________
At the large financial institution where I've been working lately, there was a different problem with the reporting
hierarchy: no one on the team reported into the team. In fact, the team was composed of individuals who reported
into a "center of excellence". This had the effect that people were strong specialists and had no real motivation to
have the project succeed.
I recently had the bounty of working with Mary Poppendieck for several days on a related project at the same large
financial institution. She pointed out that there is an underlying problem both with what I encountered, and I
believe, with what you are describing: sub-optimal measurements.
It is true that both reporting structures also are problematic, but my guess is that the worst of the effects of these
poor reporting structures can be mitigated by introducing Lean-based performance measurements. If people's
performance is measured based on their sphere of influence rather than their sphere of control, then people will work
together.
Mary describes three important measurements:
1. Business Value delivered by the project: The team is measured on this basis rather than individuals on some other
metrics.
2. Process Cycle Time: The time from the start of a project to the moment when it is delivered to and accepted by
the customer.
3. Process Cycle Efficiency: How much time is value-added time vs. the overall time spent on a project.
74
From: Jim York jim.york@ccpace.com

Subject: Reporting Hierarchies
43
These three measurements can all be improved by an empowered team (regardless of its internal reporting structure).
If the performance of individuals in the team is measured by these team-level metrics, then individuals will work to
maximize them. And True Goodness will result.
:-)
Mishkin.75
________________________________________________________________________
Great points Mishkin. Team-based performance evaluation based on the metrics Mary proposes will go far towards
"True Goodness," as you say. Individual performance rewards are almost always sub-optimal. Finding a way to
move the individual's performance feedback towards team-based metric, say 60/40 split, team versus individual, is a
good place to start.
Jim76
75
76
From: Mishkin Berteig mishkin-Agile@berteig.com; Sent: Thursday, January 13, 2005 at 11:41 AM
From: Jim York jim.york@ccpace.com
44
Section Four:
Development Practices
45
4.1 Best Practices

What's confused me on this thread is what the expectations of a best practice are. Any method of any kind will work
better in some situations that others, and work better with some teams than others.
It's not written anywhere that a best practice will work even 50% of the time, but it's implied that a best practice has
been used successfully more often than not, and has a clear and common problem it solves or avoids. Using a
scalpel to make incisions is a best practice for surgeons, but there are some situations (e.g. a headache) where using
a scalpel would be ill advised: part of defining a best practice is defining the situations it applies well in, and which
it doesn't.
While I agree that some practices are more universal than others, the more universal they are, the more basic the
problem they're trying to solve. The more complex the problem, the fuzzier the toolkit of solutions will probably be.
And since projects are complex, and teams are complex, it's inevitable that some best practices conflict with each
other. This isn't evil it just implies that project managers or team leaders have much work to do beyond reading
about and following lists of best practices: they have to be using judgment and awareness to decide which things to
apply, and when, and what actions to take when their are conflicting intelligent opinions about the best course of
action.
This is part of my problem with tight adherence to any methodology: it applies a singular context to the project and
team that may or may not be useful. It seems best to start the other way, with the needs of the project, and the
background of the team, and choose/blend a methodology based on what best serves both the project and the team.
(Advice I guess I'd offer as a methodological best practice :)77
________________________________________________________________________
In agreement, though the best practices I've seen as referred to as best practices did not work a majority of the time.
The most memorable one is having all the progress diagrams and artifacts pinned up in one room nicknamed the
war-room. Rather than being a nerve center for the project, and promoting a clear communication channel to
management, the room became a "torture chamber", where members of the team were defaced by executives and
senior management could hear the yelling even with the door closed.
Another one that makes me shudder was how feedback sessions were done at this one place. They all boiled down
to people making personal attacks back and forth.
Too many people cling to "best practices" without understanding why they are best practices. It's the understanding,
not the practice that makes the biggest difference in the practice's success rate.
Best practices reminds me of some haunting phrases...
"We did it like that at another site"
"In his book, he said we should do this"
"We should do it this way because I have more years in the industry than you do"
"I know what's best. Trust me."
"I've written several books on the topic."78
77
From: Scott Berkun scottberkun2002@yahoo.com; Sent: Wednesday, November 10, 2004 at 3:54 PM
Subject: Re: Observation for Best Practices...
78
From: Chris Pehura chris@pehura.com; Sent: Wednesday, November 10, 2004 at 5:21 PM
46
4.2 Implementing Agile on Your Own

Hi All,
As a lurker on this list for about the last 10 months, I would like to make some observations on the - ahem - robust
discussion that has been going on the nature of Agile development, standards, etc.
We have implemented a development approach here that started by applying the material called "Scrum" and the
material called "XP". Neither myself, nor anyone else here is a certified ScrumMaster, XP Wizard or has any other
qualification in "Agile". We are all however, experienced software developers.
What we did was look at the development organization we had that was not delivering. We read some of the
publicly available material on Agile methods and read Ken's Scrum book and a few of Kent et al's XP books and the
Agile ecosystems book (spending in total probably under $100 US).
Then we tried stuff, we listened to each other's suggestions, we implemented some, and we threw some away and
tried again. We've been doing this for about a year now, and continue to do it.
During this time, we found we delivered software. On time. Within budget. To customer's great satisfaction. We
also found that the team got happier, and had better lives.
I feel no compulsion at all to determine whether we are "doing" Scrum or XP or Crystal or whatever: we are doing
something that works, which we came to through /guidance/ provided by the thinkers who call themselves the
"Agile movement".
Is this perhaps the problem here? Is the very essence of Agile development that good people get together,
communicate and cooperate to do what works for them in their situation? If this is the case, is it futile to try and
encode it beyond the point where we are now?
Cheers,
Leo Zancani
Zynap Ltd.
47
4.3 Daily Builds

During our first Scrum project (currently Sprint 7) we got nightly builds working early in Sprint 1 but didn't really
see the point of anything more frequent. It didn't take long, however, to realize that more frequent builds did have
advantages so we moved to continuous integration (up to 30 or more builds per day). It certainly improved our
confidence in the code base and improved our efforts from 1 or 2 failed builds per day to it being a very rare
occurrence.
The point is we realized the benefits ourselves and so implemented the practice.
Ian79
________________________________________________________________________
Do you feel there is a point where the ability to deliver quickly is overcome by the number of builds? Doing
upwards of 30 builds a day seems like a lot of time being spent during an 8-hour day (like a build every fifteen
minutes). Then if you take into account the cycle time for a build, it would seem to leave you with very little time to
actually improve/extend the software.80
________________________________________________________________________
The build is, of course, automatic. A service listens for check-ins to the source control and, after a short delay to
allow for multiple files, kicks off the build, unit tests, etc. If the build fails, an email is sent to the whole team to
finger the culprit!
As an aside, these builds are not available to the tester on the team but the build also generates installation files so
that when the tester requests a latest build, we can simply pick the latest install file and it takes only a minute or two
to deploy to the test environment. This means that integration and test builds barely appear on our radar as
impacting productivity.
Ian81
________________________________________________________________________
Congratulations, this is continuous integration nirvana!
As a contrast, I started coaching a Scrum adoption recently where the team has a two and a half day build and test
cycle (really). When they check their changes in, their changes go to a unique branch in version control for that
developer.
When the team wants a build, a wholly separate CM group takes all the individual developer's branches and merges
them into the baseline, one by one, with much pain and many restarts.
The build itself is composed of a series of manually triggered scripts, with manual file copies and tweaks in
between. The build often fails to configure together the correct set of modules, so it often fails tests due to out of
date modules. Once they actually get a build, the automated tests take about seven hours to run, and the automated
tests cover less than 50% of the system functionality.
79
From: Shimmings, Ian ian.shimmings@conchango.com; Sent: Monday, September 13, 2004 at 3:25 PM
Subject: RE: Re: Intermediate Result Presentation
80
From: Mike Dwyer mike.dwyer1@comcast.net
81
From: Shimmings, Ian ian.shimmings@conchango.com
48
Which team will get better feedback as to the true state of their system? ;-)
I'm curious, what realizations did the team have that made them move towards faster build cycles? Were there
specific incidents, or what motivated them to take it to that level?
Regards,
Paul82
CEO, Principal Consultant: Agile Logic http://www.Agilelogic.com/
82
Paul Hodgetts phodgetts@Agilelogic.com
49
4.4 Daily Scrum Meeting

For example, is a "Daily Scrum", a "status meeting", a meeting "to identify issues", a "testing results" meeting, a
"configuration management" meeting, an integration meeting, a sharing knowledge meeting, a meeting to hunt to
spontaneous collaborations, a "team building" exercise, or a place to share stories?
Well, it is all of the above. And the same is true for many other Scrum practices they are multi-purposed.83
83
50
4.5 Scrum of Scrums

Hi everyone; I just signed up with the group yesterday. I have a question / looking for advice on the Scrum of
Scrums.
I currently have 4 Scrum teams all working of the same code base / project, each team consisting of 6 people. I have
two daily stands up sessions, one at 9:30-9:45 for two of the teams (in separate rooms / areas), and one at 9:4510:00am for the other two teams (using the two same separate rooms / areas that the first two teams use). Meeting
room space is in short supply, which is partly the reason for doing the above. Then at 10:05-10:20am I have a
Scrum of Scrums whereby the ScrumMasters for each of the four teams attend, as does one 'pig' representative from
each of the teams. At the Scrum of Scrums we ask each 'pig' representative to answer the following questions: What
did my team do since the last Scrum of Scrums? What is my team planning on doing before the next Scrum of
Scrums? What blocking issues does their team have? I also find us ScrumMaster discussing the blocking issues
although we are pretty good at keeping the meeting to 15 minutes.
So my questions are:
1. Is this the recommended approach when using multiple Scrum teams?
2. Do other people hold the Scrum of Scrums straight after the daily Scrums or do people have better suggestions on
timing?
3. I feel for some of the team members instead of just being involved in a 15 minute daily stand up, they are
involved in 30-45 minutes of stand ups, which feels too much. Am I basically on the right track with my approach
or can I refine it?84
________________________________________________________________________
Responses. Much agreement and added suggestions:
1) Scrum of Scrums (SoS) meet daily for first and last week of every Sprint but not that often in the middle.
2) After 8 or 10 SoSs, the only question asked and answered was impediments
-- Editor
84
From: "dtrowern" dtrowern@aol.com

Subject: Scrum of Scrums
51
4.6 Sprint Goal

I use Scrum with user stories. I use the Sprint goal to encapsulate the business functionality that the user stories
achieve when they are combined this business functionality is meaningful and tangible to the product owner. The
engineering tasks identified during the planning meeting (and adjusted daily through the Scrum) represent the work
to be completed to deliver the user stories, and collectively the business functionality. If development goes awry
and the engineering tasks cannot be completed, e.g. due to re-estimates exceeding the remaining time, then the
Sprint goal gives the team latitude to re-interpret the user stories and find an alternative aggregation of work that still
delivers the desired business functionality and is acceptable to the product owner.
The Sprint goal provides the team with the flexibility to constantly assess, through their daily inspection and
adaptation, how they can best achieve the business functionality given their situation and disposition. It does not
lock the team into a single and fixed set of mandatory engineering tasks that provide the business functionality.
The great thing about user stories is that they come with acceptance tests, which also help to describe the desired
business functionality. The acceptance of the Sprint during the Sprint Review includes a demonstration of the
acceptance tests passing for each user story (currently these are a mixture of manual tests through the UI and
automated tests using FitNesse) and, based on a free-format session where the product owner gets to play with the
delivered business functionality, a more holistic assessment by the product owner of whether she has the business
functionality she requires, in some shape or form.85
85
From: Simon Baker simonbaker@think-box.co.uk; Sent: Tuesday, November 16, 2004 at 4:38 PM
Subject: The Sprint Goal
52
4.7 Task Size vs. Effort vs. Duration

Dan I agree with you completely. The only addition/distinction that I make is that there are three estimates: size,
effort and duration. The effort estimate is how many hours it will take to do the work. The duration is the elapsed
time that will be required to undertake the effort hours. In my world, size is in bananas (or whatever you want),
effort is in hours and duration is in days. Just a nuance that keeps the concepts straight for me and everyone that I
work with.
Bud86
86
From: Bud Cookson bud@ridgelinesoftware.biz; Sent: Wednesday, June 21, 2006 at 2:13 PM
53
4.8 Task Size (Breaking Down Tasks)

When should large tasks be broken down into detail tasks and who should do it?
The sub-teams should break down the tasks and the Product Owner should be there to help if clarification is needed.
Sub-teams should also communicate if there are things that they are depending on each other for. We stick to the
16-hour rule as best we can; it's going to be an ongoing effort until everyone understands the reason for doing it.
Additional advice...when the teams (sub teams) are formed, make sure they go through a team building exercise to
give themselves an identity (team name or logo), and they establish their common goal/mission, and how the team
will add value to the project. It is important for the team to learn the strengths of each player, and figure out how
they are going to optimize what they've got.
Bob Schatz
CTO of Primavera
54
4.9 Sprint Calendar

Being new to Scrum, I stumbled on a question while reading through the Scrum books:
Seeing as how a Sprint is defined as 30 working days, what is the experience with teams trying to keep straight in
their head where they are in relationship to the Sprint end? In other words, since there is no correlation between day
X of a Sprint, and the Xth day of the month, do people get confused?
Does it make more sense to start a Sprint on the 1st working day of a month, and end it on the last working day of
the month? Obviously, if a Sprint were ever terminated abnormally, or if a "Release Sprint" is undertaken for less
than a month, then even this will fall into the same trap...
How do people handle this? Does the ScrumMaster keep some sort of "This is day X of Y" flip chart in the team
room?
Thanks,
Jay87
________________________________________________________________________
Jay-This is one of the reasons I use four-week Sprints (or, for some teams two-week Sprints). It's much easier to keep
track of, the regular rhythm is beneficial, and teams like setting it up so that Sprint planning always happens on a
Friday or a Monday (or whichever day they prefer).
--Mike Cohn88
________________________________________________________________________
A highly visible burndown chart also helps with this, so long as the chart shows each day of the Sprint to scale.
Team members get a sense for being 1/3, 1/2, 3/4, etc. through the Sprint.
Interestingly, I just visited an organization where the crafty ScrumMaster posted a flipchart reading "Day X" of
Sprint. I thought this was a great idea.89
________________________________________________________________________
Yes, I agree... the burndown is the simplest, most accurate way to know "where are we? Nothing like a Big Visible
Chart that you can take in at a glance.
Another thing we did, was tie our Sprint dates to the monthly reporting cycle of our PM. Since his reports were due
on "the 1st Friday of the month" (or some such) we made an abstract calendar for our Sprints, which had us always
finish Sprint Planning in time to feed into his management report. This way his projections for the month were
actually generated by the team!
So our Sprint Planning always happened on the 4th Monday of the prior month, and we ran our Sprint for 4 weeks
from that point. We knew that our Demo would always fall on the 3rd Thursday of the month this allowed us to
plan our Demos way in advance (getting large rooms and multiple customers available at once was a challenge).
Being calendar-based, twice a year we had a 5-week Sprint. Or a free week to do cleanup, or whatever.90
87
From: Jay R. Gindin jayg@blarg.net; Sent: Monday, December 06, 2004 at 11:29 PM
Subject: Sprint Calendars
88
89
From: Victor Szalvay victor@danubetech.com; Sent: Tuesday, December 7, 2004 at 3:08 PM
90
From: "Deb" deborah@hartmann.net; Sent: Tuesday, December 7, 2004 at 11:02 PM
55
4.10 Estimates
If we have a meeting like "HR Meeting on Harassment" we don't include that as a task. If it's something like
"Schedule a meeting about the xyz design" that we write up (as a task card, for us) we do put a number on that and
do write it as a task, mostly so we don't forget about it. The interesting thing about meetings is that they add
predictability to your burndown. For example, if 5 of us need to meet about the xyz design for (we think) 2 hours.
We put 10 hours on that task card. Meeting estimates are much more accurate than coding estimates, for example.
So, we'll meet for 1:45 or 2:10 and that's pretty close to the 10 hours total we planned. Next day we'll have burneddown 10 hours for that meeting. There's nothing wrong with this except it's something to be aware of. For example,
my current team starts each 2-week Sprint with around 250 hours of work planned. If a lot of that is meetings (it
shouldn't be) that 250 might be fairly easily completed. If none of it is meetings, it might be hard to finish all the
planned work.
In general, any time I know something new about a task, I update the card. So, in your example below if I have a
"code the xyz" task that I think is 5 hours but then discover I need a big meeting. I'll keep the "code the xyz" task
card (possibly increasing or decreasing its estimate) but may add a new card saying, "xyz design meeting, 6 hours"
(6 = 2 hours * 3 developers). If it's "a couple of hours" I don't bother changing the card. By the way, all these cards
are hanging on our wall so we can all see them and update them continuously. I can provide a photo if it would
help.91
91
From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Monday, September 27, 2004 at 2:33 PM
Subject: RE: Seeking Some Experienced Advice
56
4.11 Estimating Testing

I'm a tester who's trying to wear the ScrumMaster hat for three teams in a company that's never done Scrum before.
Each team has 1-2 testers, and 2-6 developers who do varying degrees of testing on their own work. Testing has
been fairly informal, but there is some push to make it more documented and formal. The testers claim they can't
give time estimates for their tasks and my experience with testing makes me tempted to agree with them. What am I
overlooking? How do you estimate testing time?
Thanks in advance for your wisdom and experience,
Liz92
________________________________________________________________________
Testing effort has traditionally been hard to estimate because what was really being estimated was the code quality
that the programmers would deliver. And that was impossible. In Scrum, however, where the programmers should
be delivering pretty high quality code to start with, estimating test effort is quite feasible. Besides, the programmers
should not be throwing the code over the wall to the testers, so the testers should be testing much earlier and more or
less continuously through the Sprint.
That's all nice and vague, though. Here's exactly what I do:
During the Sprint planning meeting we list every task we can think of to finish the potentially shippable product
increment. Obviously that means things like "Code the UI" and "Code the abc class. But, it also means we write
down tasks such "Write FitNesse tests for the abc class" and "enhance the UI tests to cover the changes to the xyz
screen. For each user story / feature we pull into a Sprint, we discuss (right upfront during Sprint planning) exactly
how we will test it. If it's a FitNesse test, we may write tasks such as "Code fixture for xyz" and "write FitNesse
tests for xyz. We don't specify the tests during Sprint planning but we decide if we are testing at the UI level, at the
service level, or just with automated unit tests. These tasks are easily estimatable. The tester may suggest the first
estimate but the programmers may often commentary on the estimate such as "No, this will take much longer to test.
There are lots of variations. Or "No, this one will be easy to test and I'll show you all the unit tests I'm doing."
Also, even if something *is* hard to estimate, take a guess and refine that guess every day during the Sprint.
--Mike93
________________________________________________________________________
Estimating is hard for everyone; I don't know why it should be any harder for testing than for coding. Mike's
approach of specifying testing tasks on a card, eg., "write FitNesse tests for the XYZ story" really helps. If this isn't
enough to help you estimate, you can break it down even further: "Work with product owner to define details of
story", "Define test data", "Specify test cases". The problem with that is that you may end up spending too much
time to come up with the estimate. But it might be a way to learn to estimate.
It's my own experience that testing tasks for a particular feature usually takes between 30-50% of the time spent
coding it. Most fall in the low side of that, but if it's technology new to the team, integrating some 3rd party
product, or something unfamiliar to the testers, it could be even 100% of the coding time. As Mike says, look to the
programmers for guidance. Your testers will get a feel for it over time. I found we had vastly underestimated some
testing tasks one Sprint, so the next Sprint I upped the estimates for similar tasks.
I think it's important for the entire team, programmers included, to take ownership for all the testing. Everyone will
get a better feel for how long it takes and with collaboration, it may go faster than you estimated!
-- Lisa94
92
From: Lizard <muddlizard@g...>; Sent: Friday, December 17, 2004 at 7:54 PM
Subject: Newbie Q About Testing Time Estimates
93
From Mike Cohn mike@mountaingoatsoftware.com; Sent: Saturday, December 18, 2004 at 6:06 PM
94
From: Lisa Crispin <lisa.crispin@a...>; Sent: Tuesday, December 21, 2004 at 4:47 PM
57
4.12 Planning and Estimating Tasks

Our backlog consists of stories, each of which is estimated using a coarse-grained points system (0.5, 1, 2, 3 or split
it please). The team signs up for the number of points it delivered last time. THEN, the team breaks down these
signed-up-for stories into tasks, which are estimated in hours. (The reasons for doing this have much to do with the
team's need to manage itself better during long 4-week Iterations, and is largely historical.)
It is the TASK estimates that we halved. The upshot was that we did them faster, and so brought some stories
forward. Which we also split into tasks with halved estimates. Next Iteration we had higher Yesterdays Weather,
so we scheduled more story points. Again, when we broke these down into tasks, we estimated their time at the
50% point (ish). We delivered all the story points. And again in the next Iteration.
So to answer your question: We didn't change the points estimated on stories in the backlog. We only changed the
process at the start of each Iteration, when the team worked out how to subdivide and deliver those stories. We
changed that process by introducing a slight of hand whose effect was to drastically reduce the effects of Parkinson.
________________________________________________________________________
Ah, you're right, that story/task thing was what I had missed.
Thanks.
I like task breakdown at planning time, as a design step. I like to see the tasks written on the whiteboard. Very
frequently, however, when teams sign up for tasks, I see problems. The problems include:
- Task programmer does too much;
- Task programmer does too little;
- No one notices a task not needed after all;
- No one notices need for a task that wasn't mentioned;
- Tasks don't add up to equal the story.
Some of these, externally, would look like Parkinson's Law.
Crunching the time allowed for each task would help with these, if through no other means, through allowing less
time to do too much, and getting to story integration sooner, to discover the other issues.
I used to recommend having a story owner, in addition to task owners, and that is still IMO a good idea if you're
going to schedule and work on tasks.
But I think that a better idea is to sign up /only/ for stories, not for tasks. The story owner sees the tasks and works
with all the necessary people to get things done, taking what people call a "vertical" slice through the system,
meaning cutting down through all the levels of the code: GUI, model, database, etc.
This works well with a team in a room, less well the more separated and more specialized a team is.
And it works better the smaller the stories are.
________________________________________________________________________
Thanks for helping me express it all in a more understandable way, Ron.
Thanks for sticking with me until I got it. My theory at the moment is that the smaller time boxes get at the
problems I listed above /indirectly/, by reducing the time to overbuild, and decreasing the time until the thing is
integrated and the other problems discovered.
But I'm wondering how your team addresses making the tasks "add up" to the story? Some teams, I think,
accomplish that by letting the GUI task serve as the integrator. (I think that's not the best idea.) How do you get
things integrated or added up?
Does the above undermine your thought experiment below?
58
________________________________________________________________________
Well, it supports my standard theory that smaller stories are better, down to a day or two anyway. I'm not sure about
the time-box idea, but I suspect that if a person worked by taking a multi-day story and slicing it into mini /stories/
rather than little /tasks/, and implemented it punching through most or all of the software layers, it would work
better.
So if in two (or more) time boxes, my focus was on story completion rather than database reorganization, I think a
team would get at the root causes that your short estimates are getting at indirectly.
________________________________________________________________________
For me, the distinction between size estimates and duration estimates is crucial. Much trouble ensues when size
estimates are expressed in time units. This is why I believe Mike Cohn is correct to favor Relative Sizing Points (or
bananas, or gummi bears) over Ideal Days. Both are estimates of size, but the second implies a duration and chronic
confusion will follow.
Remember that the size of an item is unchanging. My most frequent analogy (which I stole) is that of cutting grass.
The size of the job is expressed in acres, say 2 acres. The length of time it will take to mow this amount of grass is a
duration estimate, which is dependent on many things (equipment, number of people, weather, etc.). The size of the
job, 2 acres, never changes.
So, backlog items are given size estimates. Tasks are given duration estimates. It is at the task level where an actual
duration is estimated.
Dan Pierce95
________________________________________________________________________
I like this idea of size vs. duration. We never estimate duration of tasks; we only ever estimate size of backlog
items. Initially our estimates were time-related, but that brought all sorts of trouble. Once we moved into size
estimates, the troubles pretty much stopped completely.
I actually believe that time estimates for tasks depend on so many factors that they become virtually meaningless.
Resources become available or unavailable as you go along and the environment changes all the time.
If a given task is executed by resource A, it will take 4 hours. Resource B will need 8 hours (lack of domain
knowledge or technology skills). At the beginning of a Sprint it is virtually impossible to tell who will execute a
given task, so how are you going to estimate time? Sometimes what appears to be simple grows out of all
proportion and sometimes something that appears complex collapses into nothing because somebody digs up a piece
of information that wasn't available during the estimating. If one wanted to pin down exact time estimates, this
would require exact knowledge of resource availability and very soon one would find oneself back in the world of
waterfall.
The temptation is strong, but from experience I'd have to say, stay away from it.
In addition, what are the time estimates going to be used for? At the end of the Sprint the amount of work remaining
(in hours or whatever unit you like) is meaningless, as is the amount of actual work done. The only thing that counts
is the number of backlog items DONE.
95
Dan Pierce, Embedded Software Development Manager
Thales Communications, Inc.
22605 Gateway Center Drive Clarksburg, MD 20871
59
To stay with the analogy: it doesn't matter how many people or hours were needed or whether it was raining or not,
the only question that remains is: has the grass been mowed on all of the 2 acres?
Regards,
Wolfgang96
96
From: Wolfgang Schulze Zachau wolfgang@mobilefun.co.uk; Sent: Wednesday, June 21, 2006 at 8:07 AM
60
4.13 Technical Debt Big Refactorings Not Yet Done

On Thursday, January 20, 2005, at 7:47:10 AM, Paul Wilson wrote:
> I've been using a cut-down Scrum to manage some freelance work I've been doing recently. (Development team
== me). It worked well, keeping the client and me tightly focused on the weekly increments.
> I had an issue with how to track technical debt issues in the product backlog; when planning the next Sprint it's
difficult for the product owner to prioritize (or even care about) non-functional items. Mike Cohn makes the same
point in his (excellent) User Stories book, and suggests having only Stories in the backlog.
> Never the less, I feel these big refactorings do need to be done: hence they should be planned, tracked, and made
visible at least to the developers. How have other people coped with this problem?
Here's what I try to do...
1. Write code that doesn't need refactoring, by removing all duplication and other code smells immediately. Learn
to recognize refactorings before they're big. I believe that there are always signs.
2. Make a note of a needed "big" refactoring and put it somewhere where you won't forget it. If the bad code is not
slowing you down, don't do anything about it. If you never work in that part of the code again, the refactoring
wasn't needed.
3. If you do work in the area and the bad code does slow you down, see whether you can make a little improvement
each time you pass through, rather than bite the bullet.
4. If the bad code continues to slow you down, you'll feel increasing pressure to fix it. I'm not sure why just bearing
down a bit in item 3 isn't enough. If you must divert to fix it, try not to take the whole bite. My experience suggests
that there's usually a way.
5. If the bad code is still slowing you down, estimate whether fixing the whole thing will really give you a net
speedup. This is a function, among other things, of how close you are to the end. Then decide whether to go all the
way. My experience suggests that this is usually a mistake.
None of these things can be done perfectly at least by me. I see it as a sort of escalating thing. I believe it is
probably possible to work mostly in the 1-3 range. I believe this keeps the pace mostly constant, while 4 and 5
usually involve too much speculative investment in the future.
Now then... it seems to me that what I'm really describing are points on a continuous curve, not steps in a planned
approach. I'm not sure what to do with that observation.
Ron Jeffries97
www.XProgramming.com
97
From: Ron Jeffries ronjeffries@XProgramming.com; Sent: Thursday, January 20, 2005 at 8:07 AM
Subject: Re: Technical Debt and the Product Backlog
61
4.14 Requirements Ready for Sprint

I recently joined a software company that started using the Scrum process. We are finishing up our second Sprint.
We are generally satisfied with Scrum, but are having a problem in having the requirements ready for the beginning
of the Scrum. The people who write our requirements are spread around geographically but the development team is
all located in one place. We are looking at having an even heavier process to define the requirements because of the
geographic issues. I am concerned that we will have a mismatch between the 2 processes. I would be interested in
hearing from others who have had project with similar issues and what they did to solve the issue.
Thanks.98
________________________________________________________________________
You should have a backlog of prioritized, "ready" requirements. The product manager should be collecting
requirements into that backlog. By making it clear when the cutoff date is for requirement submission for the next
Sprint, the customers know when they have to get their requirements submitted. When the next Sprint starts, its
requirements come from the backlog. If any customer is late getting their requirements in, then those requirements
just go on the backlog for a later Sprint to do. If enough customers are late with their requirements, then the backlog
will be quite full enough that it is never a problem to find requirements for subsequent Sprints.
Perhaps, customers are having trouble "writing" requirements because they are being asked to document their
requirements in too much detail. A brief description should be enough to prioritize requirements. The details can be
collected during the Sprint when it is actually being implemented. This approach prevents the details from getting
stale over time, creates an opportunity for constructive communication between developers and customers that
makes the requirement better understood than any written documentation can, and makes life easier for customers.99
________________________________________________________________________
Without getting pedantic, I would like to point out that one of the key attributes of Scrum is the collaborative nature
of the working relationship of the user/product owner and the Scrum Team. From what little you have told us, one
could draw the impression that you are actually doing timeboxed waterfall tasks where requirements are built by
separate teams and then handed off to the coders. There is nothing wrong with this, as it is a common way for
organizations to get comfortable with the methodology.
It might be a good time though to blur the lines between the requirements and the coding by using the product
owner's priority of the backlog create the need to assemble Scrum teams made up of people from the two previous
Sprints. This is not an endorsement of jumping whole hog into Scrum, rather it is a suggestion to let the product
owner's priority drive the melding of the development team.
--Mike Dwyer100
98
From: "tiggerbob_93003" bbrodie@epolicysolutions.com; Sent: Wednesday, March 16, 2005 at 8:31 PM
Subject: Requirements Process and Scrum
99
From: Steven Gordon sagordon@asu.edu; Sent: Wednesday, March 16, 2005 at 2:48 PM
100
From: Mike Dwyer mike.dwyer1@comcast.net; Sent: Wednesday, March 16, 2005 at 9:59 PM
62
4.15 Testing
I've never used Scrum on a project that was done in a scripting language, if that's what you mean. We have used
scripting languages as part of our approach to testing. The tester needs to be an integral part of the team as much
so as any programmer. I like to have the tester spend some time talking with the customer about the likely stories
(features) coming into the *next* Sprint so that when the programmers start coding they already have high-level
acceptance tests written. We like to capture these in FitNesse. Involve your tester in more discussions and have her
use the strengths she brings to the team presumably she's a good tester despite your comment that she doesn't have
strong tech skills. She should still be able to specify tests in advance or use tools such as FitNesse and Canoo
WebTest.101
101
63
4.16 Test Driven Development

I hear (and experience) things like "I started coding some tests for feature X, but they weren't working, so I spent
three hours trying to figure out if my code was wrong, and then figured out that there was a bug in Z. So I spent half
a day and accomplished nothing. It takes a lot longer to write tests for buggy programs because every unexpected
behavior you encounter must be analyzed, to check whether it's your own mistake or a real bug. So how do you
estimate ahead of time how buggy the code will be when you start testing it?
How do I encourage this paradigm shift? Right now I frequently hear "it's done, it just needs to be tested. I don't
have the power to mandate TDD yet (either management backing or respect from the team), so how do I survive
until the team itself asks for TDD and encourage them in that direction? The teams that have completed at least one
Sprint have, in their retrospectives and suggestions for the next month, made the gap between "creating the new
feature" and "fixing bugs in the feature I just implemented this Sprint" bigger.
Thanks,
Liz102
________________________________________________________________________
Hi Liz-A couple of suggestions:
1) You say that you hear things like, "it's done. It just needs to be tested." Yep, that's a very common (and
annoying) statement. I encourage teams to spend 15 minutes agreeing on what "done" means. That usually ends up
being something like "well-written, unit-tested, checked-in, etc. etc. (I don't want to write more because I don't
want to overly suggest an answer that's up the team.) I typically write this definition on a shared whiteboard for
everyone to see and remember for the next few months. I've gone so far as to buy a cheap dictionary, print our
definition and tape it into the dictionary in the right place. The dictionary becomes a bit of a joke but a symbolic
one that helps us remember our definitions of "done" as well as "trivial" (="will take at least 2 weeks") and "today"
and a few others that may come up.
2) Keep stressing that work *has to be finished* in the Sprint. That there is no carryover of "fixing" it in the next
Sprint. This is where I really like the XP idea of velocity. A team's velocity is measured by work it completes (I'd
say "all the way" but that's really redundant with "complete"). If I don't quite finish a lot of things, my velocity is
very low relative to what it could be. This helps teams understand the importance of really finishing.
3) I like to tell teams something like "I'd really like us to try TDD. I don't know how often and how much of it we
should do but I know it's not 0% and I know it's not 100%. So collectively let's figure it out." [Note: I actually do
think it's 100% but I lie and let them think I top out at 99%.] Once I get a team to start trying TDD, it's easier to
keep nudging them and someone on the team will usually start to "get it" and then it's easier.
4) I think that estimating test tasks during Sprint planning sets the stage for treating test tasks as first class citizens
throughout the Sprint. I think that will help encourage the "paradigm shift" you're after.
5) I'm not sure it really takes longer to write tests for buggy code. It takes longer to execute those tests perhaps but
you want to (a) not have such buggy code and (b) have a test automation process that lets you write tests without any
code (so buggy code doesn't matter). Find a way of specifying the tests you want that is independent of having
running code. Push this activity as early into the Sprint as you can (ideally before or concurrent with the first lines
of code for the Sprint). Tools like FitNesse are wonderful in this regard. If you find you can't do much of that yet,
then you estimate how long it will take based on past experiences with how buggy the code will be. "I estimate it
will take 8 hours to write tests for Jim's new code but since his code is always buggy, let's put 24 hours on that
card. I think that's a fair statement if Jim is that buggy.
--Mike Cohn103
102
From: "Schoof" <muddlizard@g...>; Sent: Tuesday, December 21, 2004 at 9:10 PM
Subject: Re: Newbie Q About Testing Time Estimates
64
________________________________________________________________________
TDD is hard to start doing, period. So it's much harder to do without someone in authority prodding the team to
deliver better quality. It's harder to influence the team if you're a tester and not a programmer. I feel your pain. Are
there any programmers who are sympathetic to your point of view? If so, see if you can brainstorm with them.
If you're automating your customer-facing tests, and the programmers are not writing automated unit tests, you can
point out that many of your tests could be covered by unit tests, which have a much better ROI.
You can always do what I've done and say, "Ron Jeffries said the entire team is responsible for testing, and the story
isn't done until the acceptance tests are done. (OK, I didn't say Ron specifically, but I pointed out what the many
publications on XP said, being as I was on an XP team). If your team honestly wants to benefit from Agile
principles and values, they need to try to implement key practices.
I highly recommend "Fearless Change" by Mary Lynn Manns and Linda Rising. I have used their patterns to get
teams to try Agile practices.
-- Lisa104
103
104
From: Lisa Crispin lisa.crispin@att.net
65
4.17 Unit Testing

Coding does not require unit testing. Most of the working code in the world does not have unit tests. Thus unit tests
are extrinsic.
I have drunk the unit testing Kool-Aid, but if you bypass the cost of something, you lose credibility with those you
are talking with. I have learned this through many, many conversations with developers who consider unit testing a
lot of extra work up front and a lot of extra maintenance work. Saying it's not a lot of work doesn't give you much
street cred. You and I may think we have excellent reasons for doing the work, but it is still a lot of work.105
________________________________________________________________________
Yes. However, debugging and fixing also costs a lot. So if you want to have software at a reasonably low level of
defects, it just might be that unit testing costs less than (not unit testing plus debugging plus fixing).
Ron Jeffries106
________________________________________________________________________
The real electric Kool-Aid Test lives in the dark side of software maintenance and problem resolution. Since it is
here that you can see the hubris of those who felt their code was too smooth, too simple, or too cool to need a unit
test. Is there a lot of energy in that statement? Yup. So perhaps I should rephrase.
It is rare to see code come into the shop that had well designed unit tests.
That is to say tests that:
Defined the input, tested all combinations of input, tested to make sure they could tell good input from bad.
Ensured that all logic flows had errors trapped with some meaningful documented schema to tell where the error
came from.
Validated that all the output meant the interface requirements that the users of the software had stated they needed.
Documented all of the conditions that could occur that were not covered by the interface specification.
Now the really GOOD engineers had a parm you could pass that would open up the dbug logic in the software so
that we grunts on the dark side had some idea what was going on.
Finally, speaking from my tenure as chief testing troll, the REALLY GOOD AND SMART Engineers enlisted a
testing troll in testing the tests.
Michael F. Dwyer107
________________________________________________________________________
> Todd Hartle wrote:
> However, not unit testing does not imply not testing all. And it also seems that unit testing can still exist even
though the tests do not live in the code.
If you don't write unit tests before writing code, your tests won't easily cover everything, and you will spend more
time debugging.
Folks who use TDD very frequently report _zero_ debugger usage.
Think of it like this: Each time you debug, you set a breakpoint, you run the program and load sample data, you hit
the breakpoint, and you inspect the local values to see if they are correct with respect to the sample data.
105
From: Todd Hartle thartle@gmail.com; Sent: Saturday, December 4, 2004, at 1:57 PM

Subject: Unit Testing
106
From: Ron Jeffries ronjeffries@XProgramming.com; Sent: Wednesday, December 08, 2004 11:30 PM
107
From: Mike Dwyer mike.dwyer1@comcast.net; Sent: Friday, December 10, 2004 at 8:08 PM
66
TDD converts debugging into a system that records an endless trail of each of these experiments. Going forward
into maintenance, for each change you make, you get an invisible programmer debugging your code, over thousands
of scenarios, in a second.
-- Phlip108
________________________________________________________________________
Hi,
Unit testing as it is emphasized today in TDD and XP has mainly two backgrounds:
a) In XP you do not very detailed requirements analysis, but story boards and planning games, like CRC card
sessions.
So, writing unit tests first helps the programmer to understand the requirements. With "the customer in house" you
can use (and must use) the tests to validate whether your requirements are right. Further: writing a lot of unit tests
comes from the Smalltak development fraction where your unit tests partly replace the compiler type checking and
also lint.
b) Your main goal in having unit tests is to have a "regression test suit" in case you do refactorings, bug fixes or you
simply continue in your next development goal.
Finally: most software development shops have no clue how to value whether they "need" unit tests or not. If you
ask one who does not do unit tests he will ALWAYS claim he either does not need them or they don't bring him any
value (ROI). Likewise everybody doing them knows that they bring him ROI, like I pointed out in b) As long as
one without unit tests never does one, he has no numbers from which he could judge. Most of the time, people
without unit tests have no decent issue tracking/bug fixing/project tracking either. So how should they know how
much it costs them NOT TO DO TDD?
I disagree that detailed requirement analysis does not work, and also I disagree that the tests are needed to get the
requirements fixed. Often this may be the case but as a general rule, its far to strong.
Suppose you don't do a use case and a few scenarios, but write the test and the code, which passes that test. And
now? Now you check whether the code/test is right. Thats expensive, especially if the code and test is wrong!
Before you code, regardless whether with TDD or not, you should do planning games with paper sheets where you
have a paper form holding data and objects and you pass them around between requirements analysts like in CRC or
XP planning games.
If you start directly with TDD you are not "coding" but "prototyping" ... a completely different approach with
different goals (throw away e.g.).
Regarding OOP reinvented unit tests ... no they did not. In OOP unit tests are far more complicated than in
C/Pascal like languages because its harder to write stubs.
Instead of writing unit tests, I always start with writing tests based on a scenario. That does give me an integration
test over a small subsystem. All scenarios should cover all the code written for a full use case. A coverage tool
helps. When the software evolves and "libraries" for it get crafted and refactoring gets more and more we start
writing unit tests. In general we have far more "scenario" tests than unit tests. As some posters here were right: that
bad code we don't write. So if our scenario tests have a full coverage we hope they hold. We don't make avionic
systems here :D But well, that risk we judge depending on likelihood and cost of failure.
Regards,
Angelo109
108
From: Phlip phlip2005@gmail.com; Sent: Friday, December 10, 2004 at 9:25 AM
67
________________________________________________________________________
> Gary F wrote:
> Other types of testing don't have the same benefit with regard to debugging that unit tests have. They certainly
have other types of value, but unit tests provide a tremendous tool for isolating bugs.
TDD often goes a little farther, into preventing bugs.
When you write a failing test, you take care that the test is minimal, but it fails for exactly the correct reason.
When you make the test pass, you are allowed to lie. Returning to a green bar is more important than making the
code honest. This implies one often takes more care to ensure a test fails for the correct reason than one takes to
make the test pass!
If you know the code lies, you must write more tests that expose the lie. When these tests get their green bar, you
are free to refactor the code. Minimizing it and resolving duplication overwhelmingly crushes out opportunities for
bugs. The leanest code that fits a set of tests has no room for bugs.
One practices the technique of using tests to force out temporary lies, even when you don't know the code lies.
In greenfield projects, when adding logic-driven features, this form of TDD rapidly drives code into a rock-solid
situation with vanishingly small chances of bugs.
-- Phlip110
________________________________________________________________________
The tests are not part of the code, they are written test plan/cases that someone can follow or that can be automated
via WinRunner or the like.111
________________________________________________________________________
That's the "traditional" way to do it.
The first layer of tests must be written by developers, in the same language as the source, and at the same time as the
features they test.
That will provide enough decoupling and infrastructure to then write "acceptance tests", using essentially an
alternative program user interface.
Testing thru a GUI adds a lot of burden, reducing the value of the tests, and reducing the turnaround on feedback
from decisions.
-- Phlip112
109
From: Angelo Schneider angelo.schneider@oomentor.de; Sent: Saturday, December 11, 2004 at 5:25 AM
From: Phlip phlip2005@gmail.com; Sent: Sunday, December 12, 2004 at 9:51 PM
111
From: Todd Hartle thartle@gmail.com; Sent: Monday, December 13, 2004 9:17 AM
112
From: Phlip phlip2005@gmail.com; Sent: Monday, December 13, 2004 at 7:21 AM
110
68
4.18 Bugs How to Handle

A lot of this depends on the context, the number of bugs, and your Sprint length. A team I'm working with right
now had some legacy code quality issues that led to lots of bugs. We started with a goal of fixing all showstoppers
during the Sprint in which they were found. Naturally, we couldn't predict when a showstopper would come in yet
we scheduled them into the Sprint by committing to fixing them and knowing there would be some number of them.
Once showstoppers were being fixed within the Sprint, we decided, "The sun shall never set on a showstopper.
We've held to that for 6 months now. Then we decided that we'd finish every Sprint with no High bugs reported
against the system. (I'm not saying that we'd fix all Highs we newly introduced that should be a given. I'm talking
about fixing Highs discovered in legacy code.) It took 3 Sprints of including some amount of time planned for High
fixes before we got them close to 0. Now we just know that if a High or Showstopper comes in we fix it. We don't
quantify that amount of time.113
113
69
4.19 Retrospectives
Kerths Prime Directive
Regardless of what we discover, we must understand and truly believe that everyone did the best job he or
she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation
at hand.
Norman L. Kerth, Project Retrospectives, Dorset House Publishing, 2001
I usually take a very simple approach to this. All I want to know after each Iteration is:
--What should we start
--What should we stop
--What should we continue
We refer to this as a start/stop/continue meeting. Depending on the team, how I think they're feeling, my mood, and
pure chance, I'll facilitate the meeting in a variety of ways. I may go around the room asking each person for one
item or one item in a specific category. I may ask generically "what should we stop" and see who answers. We do
this for 30 minutes (roughly) at the start of each Sprint planning meeting.
Mike Cohn114
________________________________________________________________________
I am finding that many new ScrumMasters are not logging and tracking blocks. If you have done this rigorously it
provides a map of everything that went wrong.
Going through that list in the retrospective, checking off what was fixed, and evaluating what to do about open
issues will generate a strategy discussion on how to move into the next Sprint. You can add the usual issues that
come up around team function, attitudes, missteps, etc.
Dealing with the blocks is the key to unleashing a Scrum and forcing a transformation of the company.115
________________________________________________________________________
Consider looking at (to name a few possibilities):
-Backlog items selected and finished
-Number of bugs introduced/fixed and other bug trends
-Significant events that happened during the Sprint
Find a way to get some sense of how people felt about their work, maybe with a histogram that shows how satisfied
people were with their process and product.
In my experience, starting with data and some sense of how people felt about their work results in deeper insights
when it comes to answering the question: What would we do differently?
I've posted some notes on retrospectives (with pictures) here:
http://www.estherderby.com/weblog/archive/2004_10_01_archive.html#109741752540200367
Esther116
Esther Derby Associates, Inc.
114

From: Jeff Sutherland jeff.sutherland@computer.org
116
From: Esther Derby derby@estherderby.com
115
70
4.20 Implementation or Customization Requirements

What practices support a disciplined and Agile approach to installation/deployment (customization) in the way that
TDD and refactoring do for coding? Not enough attention has been paid to this in the Agile world.
Daniel Gackle117
________________________________________________________________________
IME, the best results are obtained by treating the implementation team as a Customer with their own set of
requirements.
Bill118
117
From: "slightlynew" <gackle@s...>; Sent: Thursday, December 16, 2004 at 6:01 PM

Subject: Re: Implementation as a Discipline of Development?
118
From: Bill Walton <bill.walton@c...>; Sent: Thursday, December 16, 2004 at 12:18 PM
71
4.21 Requirements Definition Sprint

All,
A few weeks ago, I launched a discussion thread wherein I proposed a Sprint dedicated to the preparation of detail at
the beginning of a project such that the product backlog would always have a significant number of items ready for
Sprint planning. This thread became very active for a week or so (sometimes on topic, sometimes not). In many
cases, opinions were against the concept of an elaboration Sprint but most of the objections were based on the
simple fact that it wasn't how Scrum worked.
Well, never being satisfied with being told, "that's not how you do it" (and knowing that the worst that could happen
was I'd lose thirty days), I did it anyway.
I'm returning now, a few days before I hope to smoothly "crash land" this Sprint to tell all of you DON'T DO
IT!!!!
Sprints dedicated to elaboration of requirements will not work because:
1. The elaboration process required to reach an appropriate depth of information for the product backlog usually
takes only a couple days.
2. Most of the information for any given feature is usually in the heads of one or two people. Get them together to
document their findings and youll probably be OK.
3. Even if the Sprint goal is to provide a more detailed product backlog, no one can really focus on achieving the
goal of "providing appropriate detail." The measurement is amorphous. It's like saying make the program run
faster. You really never know when you're done.
4. Developers can't get charged over writing detailed requirements (which, in one form or another, is what is ending
up on the product backlog not strictly so, but close enough) the qualities of a Scrum that create emergent order
from the chaos doesn't occur.
At CSM training in Boston in November, I asked Ken about this and his answer seems to me to be the best way to
handle it just reduce certain individuals allocations to Sprints a little bit (5%), and let them work on providing
sufficient detail while other Sprints are occurring.
I am currently working to help three other development groups take on the Scrum method and I am using this
approach instead of the elaboration Sprint.
I've told my team that there will be no more elaboration Sprints in their future. Lesson learned I figured I'd pass
on the pain points.
Jim Schiel119
________________________________________________________________________
Jim,
[deletions]
Looking at your individual points, I see some things that I find interesting:
The first two points relate back to the central concept, "bring the users and programmers together and let them
discuss how it should work" as a central model for Agile development. Also, the Agile Manifesto that says, "We
value working programs over detailed documentation". If we accept those concepts at the outset, then a lot of the
"That's not how it's done in Scrum", makes more sense.
The third point lines up pretty nicely with the idea that the only acceptable deliverable is, "a functional, potentially
implementable feature". Clearly, documentation doesn't fit this bill.
119
From: James Schiel james.schiel@siemens.com SHS Malvern

Subject: Disavowing the "Elaboration" Sprint
72
I'm not sure I understand the fourth point in its entirety. I will say that our experience is that Scrum vastly improves
the individual team members' sense of job satisfaction. I imagine that consigning them to a month of documentation
hell doesn't help much there. Another point that I would add on here is to ask who decided to implement the
elaboration Sprint? Was it you, or did the team decide to do that? Personally, I made an extreme effort to back off
from the "how" aspect with my team. I help to organize, understand, and prioritize the work, but I really try to get
them to figure out for themselves the best way to get it done. We regularly have discussions about the process. Are
we meeting our commitments? Are we creating problems for ourselves? Are we getting all the information we
need? Are we communicating to the customers properly? Do they have any pet peeves? Then I try to get them to
address those issues and come up with solutions, draw a consensus and then implement them.
Dave Barrett,120
Lawyers' Professional Indemnity Company
120
From: David A Barrett dave.barrett@lawpro.ca; Sent: Thursday, December 2, 2004
73
4.22 Very Large Projects

[deletions] Where can I find some more material concerning Agile practices in large projects? That is, many
business activity areas, more than a thousand features and geographically distributed developers? Our company is
small but the scope of our projects is big.121
________________________________________________________________________
The main thing I did differently on the larger project was spend more time upfront on requirements and architecture.
The daily stand-up meetings were critically important.
Jim122
________________________________________________________________________
I would advice to take a look at http://www.jeckstein.de/Agilebook/index.html
Cheers, Ilja123
121
From: Alejandro Berganza <alex@p...> Sent: Friday, December 17, 2004 at 1:33 PM
Subject: APM for Large Projects
122
From: Jim Watkins <jwatkins@t...>; Sent: Friday, December 17, 2004 at 1:55 PM
123
From: Ilja Preuss <preuss@d...> Sent: Monday, December 20, 2004 at 5:12 AM
74
4.23 Sprint Burndown

Hi everyone,
I'm a non-practicing certified ScrumMaster, with a few questions for practioners:
1) What happens when you bite off more than you can chew for a Sprint? Do you run over? Do you descope? If
you descope, how hard is it to do?
2) What happens when you bite off too little? Do you add more? Do you go to the movies or surf the web?
3) When would you know that either of these were happening?
4) Do you ever get it exactly right (i.e. the amount of work selected fits exactly into the Sprint)?
Yours intriguedly,
Clarke124
________________________________________________________________________
Hi Clarke-As to #1: If we bite off more, we drop functionality but still try to meet the Sprint goal. I never drop quality and I
never extend the Sprint. Dropping a story from a Sprint isn't particularly hard. Because of how I track Sprints (see
"Tracking Progress" at http://www.mountaingoatsoftware.com/Agileplanning/) the team is encouraged to try to
finish one story before going on to the next. (They are naturally working on more than one at a time but I encourage
them to not randomly bounce back and forth and at the end be 80% done with 10 stories and 100% done with none.)
As to #2: I play it by ear if they bite off too little. If it's quite a bit too little (more than a day) we'll add more in,
especially if we can tell this with a few days to go. If we finish early the last day, I may encourage the team to go
home and recharge for the next Sprint or I may encourage them to pull something small out of their "personal
backlog" (not a formal list, just the things bothering them they never have time to get to). We also maintain a
"refactoring list" and we may pull something off that. If we do new things like this at the last minute we put them
into the source branch that will become the *next* Sprint most of the time. Rarely do we risk screwing up an
otherwise done Sprint by doing a refactoring on the last afternoon of the last day. Other times we'll have an
estimating meeting and assign story points to all the cards that slowly pile up.
As to #3: We can tell these are happening by watching the burndown chart and by listening to people in the daily
Scrums. Right now, we're 3 days into a 10-day Sprint (I like two week Sprints). The team started with a plan of 206
hours of work; we still have 186. That doesn't look good but I'm not panicked yet and ready to drop functionality
because I know the "signature" of this team. This Sprint we've burned down steadily (albeit very slowly) from 206
to 186 over 3 days. Most Sprints this team starts with around 225 hours, burns UP the first few days then burns
down pretty quickly over the remaining 7 days. So, even though we've burned down 10% in 30% of the time, we're
ahead of a typical Sprint for this team.
As to #4: I don't know that we ever get it exactly right in that the last test runs at 5pm on the last day but I think we
often get it very, very close. I'd consider that to be where the team gets a get solid release done with everything on it
sometime on the last day or where we drop something that doesn't impact the Sprint goal and that is made up in a
handful of hours in the next Sprint (if prioritized back in).
--Mike Cohn125
________________________________________________________________________
124
From: Clarke Ching lists@chingz.com; Sent: Thursday, September 16, 2004 at 2:44 PM
Subject: What Happens If You Bite Off More Than You Can Chew, For a Sprint
125
From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Thursday, September 16, 2004 at 8:17 AM
75
> 1) What happens when you bite off more than you can chew for a Sprint? Do you run over? Do you descope? If
you descope how hard is it to do?
Descope, in the spirit of the overall goal of the Sprint, with the explicit involvement of the goal donor. It gets a lot
easier as you do it.
> 2) What happens when you bite off too little? Do you add more? Do you go to the movies or surf the web?
If way too little, add more. If a little too little, rest or clean up the kitchen.
> 3) When would you know that either of these were happening?
In my experience, not until about halfway through the Iteration at the earliest. That's one reason why I like shorter
Iterations.
> 4) Do you ever get it exactly right (i.e. the amount of work selected fits exactly into the Sprint)?
Not that I can recall. But we get very close.
Ron Jeffries126
The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
126
From: Ron Jeffries ronjeffries@Xprogramming.com
76
4.24 New Tasks Added to List of Sprint Tasks

I have been ScrumMaster for a project the last few months. Two problems with what is going on are bothering me:
1. Almost every day, new tasks are added to the list of Sprint tasks; things we forgot about at the beginning, things
that appear because we've had to change the way something is being handled, whatever. Is the Sprint task list
supposed to be so much in flux all the time?
2. The estimates I get for tasks are invariably way off. I often get a standard "8 hours", which secretly means ("I
don't know I'll just work on it today and see what happens"). Is there a better way to arrive at better time estimates
for tasks?
Thanks for any help that comes my way,
Sam127
________________________________________________________________________
To me it sounds like you're doing *nothing* wrong, except maybe worrying too much.
Are the new Sprint tasks necessary to perform the product backlog items agreed to in the planning meeting? If so,
this is normal.
Agile methods are pretty much based on the assumption that software development is unpredictable down at the task
level. Fortunately the law of large numbers makes it possible to forecast the big picture once you have enough
velocity data. Mike Cohn demonstrates that here:
http://www.mountaingoatsoftware.com/Scrum/burndown.php128
________________________________________________________________________
Without knowing the particulars of your project, I can't say definitively, but:
1) It sounds like your tasks are either too granular or too technical (or both). For example, consider the difference
between:
* Build MySQL DAO for posting to forum
* Build MySQL DAO for comments on post
* Build MySQL DAO for RSS feeds
* Build MySQL DAO for email digest feeds
If you change the database, or the persistence layer (in theory you shouldn't be seeing changes in the featureset)
vs.
* Build persistence-backed forum with posting and comments
* Support RSS and email feeds for forum.
This is a contrived example, I know.
I'm assuming, of course, that we're talking about internally-driven technical changes because the existing technical
approach just won't work. You shouldn't be seeing any changes to the feature/function set of the project during the
Sprint. Internal or external.
2) Others may have better ideas than this, but this seems like a good place to introduce 'prototyping' tasks (or Spikes
in XP parlance) to the initial task list for development tasks that aren't well understood. The initial estimates will
still be wrong, but you should have your more accurate estimates sooner in the process.
127
From: Sam Edwards <sedwards@c...>; Sent: Monday, September 19, 2005 at 1:33 PM
Subject: What am I Doing Wrong?
128
From: Michael James michael@danube.com; Sent: Monday, September 19, 2005 at 7:07 PM
77
Another option is to use a Delphi-method estimation process, which I have found to be pretty good, and I should use
more than I currently do.
http://www.processimpact.com/articles/delphi.html
jb129
________________________________________________________________________
Warning: the following is highly heretical. It's also highly practical. Think of me as the local Jesuit.
On Monday, September 19, 2005, at 1:33:10 PM, Sam Edwards wrote:
> 1. Almost every day, new tasks are added to the list of Sprint tasks; things we forgot about at the beginning,
things that appear because we've had to change the way something is being handled, whatever. Is the Sprint task
list supposed to be so much in flux all the time?
If there's a fundamental error in Scrum, it is very likely the task list. (I await Mike Beedle's thoughtful remarks on
this assertion.
;->)
The reasons why this might be include:
Tasks can proliferate without bound;
Tasks can be used to put off doing something instead of just doing it;
Tasks can be delegation without responsibility;
Tasks take the team's eye off the ball of completing product backlog items, which is, after all, the <expletive>
point.
XP teams today often do not do much of anything with tasks, though I continue to recommend brainstorming the
tasks at planning time just so we don't forget that we have to update the Schema. It seems clear that /if/ we could
just do the backlog items without all this tasking stuff, it would be better. But it's a big "if".
Practices that support working directly from backlog items include:
Smaller backlog items. When backlog items are a day's work for someone, there's not much point in listing the
tasks. Just do them.
Less specialization in team members. When an entire backlog item can be accomplished with fewer team members
involved, there's less reason to put things on the board and take them down again.
Pair programming. If I pick up a backlog item, pair with the DB person to change the scheme, with the UI person
to do the GUI, and so on, there can be more continuity, less handoff, less overdoing and redoing, and there is of
course greater learning.
> 2. The estimates I get for tasks are invariably way off. I often get a standard "8 hours", which secretly means ("I
don't know - I'll just work on it today and see what happens"). Is there a better way to arrive at better time
estimates for tasks?
Are task estimates necessary, especially if they're being created in real time? I've found that task estimates never
add up to backlog item estimates (they are always larger) but that backlog items can in fact be implemented in less
time than the estimates say if the team just focuses on making the backlog item work.
129
From: John Brothers jbwork@undefined.com; Sent: Monday, September 19, 2005 at 1:59 PM
78
If backlog items are smaller than a couple of days, 8-hour task estimates will become a thing of the past.
Ron Jeffries130
________________________________________________________________________
Sam,
One thing you might think of is to spend more time in the Sprint Planning session. Could it be that the team and the
product owner go through the list and come to some 'kinda' agreement that has no specific FUNCTIONAL
description attached to a task? This is the value of Ron's Cards and Mike Cohn's user stories. You may want to read
up on both, as they require some thought before entering into an agreement as to what is going to be done.
Ron will rant if he wants to but the Planning game hinges on some estimations regarding technical and business that
need to be done. Of course they are wrong! That is why we refer to them as estimates. I mean when was the last
time YOU or anybody got an estimate from a tradesman that was accurate? Push back at the weenies who are
giving you a hard time about 'bad' estimates, by simply asking them how much time they estimate they will have to
work with the team during the Sprint. Keep track and then you too can get that condescending look when you sigh
and comment about their poor estimates and how they impacted the team. About 1 time is needed to keep that song
off the iPod.
Second Scrum is all about getting better. So you don't chunk well and end up with too much on your plate, cut back.
That isn't hard. What is hard is delivering when you have to no matter what. Somethings get put in the product
backlog because someone thought of them AFTER the planning session.
So? Get better next time.
Estimates. They are a synonym for wrong. BUT a string of estimates that get less and less bad show that you are
getting better. This is a good thing.
Keep Truckin' guy, take what you need from Ron, Ken, Mary P, and even my rants to build what will move you
forward, but most of all keep movin' forward by helping your team get their impediments out of the way.
Michael F. Dwyer131
130
131
From: Ron Jeffries ronjeffries@XProgramming.com; Sent: Monday, September 19, 2005 at 5:02 PM
From: Mike Dwyer mike.dwyer1@comcast.net; Sent: Monday, September 19, 2005 at 7:14 PM
79
4.25 Product Backlog

Scrum certainly doesn't require the story approach. But since the Product Owner prioritizes the product backlog,
things on it need to make sense to them. For the Sprint backlog, that's explicitly owned by the technical team and
will often have tasks in developers' language.
80
4.26 Moving Product Backlog to the Sprint

With that in mind, you want to put more work on the items you'll work on soon and less work on the ones you won't
get to for awhile. I strongly advise writing product backlog items in the form of "user stories. I don't want to plug
my book unduly but see www.userstories.com and there's a sample chapter of the book plus the table of contents.
You'll see a chapter on Scrum with stories in it. That chapter isn't online to read it you will have to buy the book!
:) User stories are likely to raise the granularity of what's on your product backlog and they make it easier to
compare items because all are listed in terms of customer or user value.
In terms of prioritizing, there are really three factors to consider. This is key because to my knowledge everyone
who writes about it only writes about one of them. Here they are:
1) The business value of the feature (that is, do the thing that will bring in the bucks) (this is the one everyone
mentions)
2) Features that will help the Product Owner clarify her thinking. For example, if I can do a feature now that will
remove a lot of uncertainty in the Product Owner's vision for the product then I should do it now, rather than in, say,
2 months, which might be where it would otherwise be prioritized based purely on #1.
3) Features with a high cost of change should be deferred until later in a release. The logic here is that if something
has a high cost of change, we should wait until we know more about the app before we do the feature with the high
cost of change.
Before everyone yells at me for violating the Agile principle that says business value is the only prioritization factor:
The other two items above are influences on business value prioritization. So, adjust things up or down based on #2
or #3. I'm not saying that an otherwise irrelevant feature that would be impossible to change should be done first.
In order to maximize business value we also need to minimize total cost of the project.
That's what the items above will do.132
________________________________________________________________________
Mike,
I heartily agree with the first 2 criteria, especially if they are applied in that order.
My experience suggests that a more effective 3rd criteria is high LIKELIHOOD of change rather than high cost. If
you do proper TDD, OO-design, and refactoring, the only features that should exhibit a high cost of change are
crosscutting features (e.g., security, localization, etc.). While I generally like to ignore such features for the first few
Iterations in order to:
- get the most central features working (criteria 1) in order to build customer confidence, and
- prime the feedback pump (criteria 2),
it is critical to not defer the crosscutting features too much longer after that.
Steven Gordon133
________________________________________________________________________
132

Subject: RE: Resource Planning and Time Estimates
133
From: Steven Gordon sagordon@asu.edu
81
I agree with your list, but I would even add more "prioritization criteria", (that way they can yell at both of us!)
4) Backlog items that reduce "business risk". Yes, it is possible to extrapolate value is 1/risk, but in many industries,
is not about "increasing the bucks coming in (revenue/profit)" is about "reducing the bucks going out (fines, bad
press, liabilities, etc.)".
5) Backlog items that allow the team to "gel" or build their confidence i.e. "low hanging fruit" items used to get
momentum.
- Mike134
134
82
4.27 Product Backlog is a Null Set

Hi.
I am currently advising a small project that has a legacy system. They do not at this time have a requirements
database. They are developing in an Iterative manner, with a lot of customer input at each Iteration. For each
Iteration, the customer sits down with the team and reviews what they like and what they don't like a lot of time as
notes written on screen shots. They save customer notes as long as the project is active (i.e., when another project
starts, they discard the old notes).
I believe that I have good way to perform requirements definition and management.
On the other hand, it seems rather 'light' than what I'm used to. Does anyone have any comments on how I
could/should shore up the requirements on the project?
Thanks.
Steve Leydorf135
________________________________________________________________________
Id recommend using a pen, rather than a pencil. :) Otherwise this sounds perfect to me.
Regards,
Mike Cohn136
135
From: Leydorf, Steven M. steven.leydorf@ngc.com

Subject: Agile Requirements Management
136
83
4.28 Definition of Done

"Tested"
Does the code have unit tests for all functionality? [Would it ever not? What about?]
Was the code written test-first?
Would developers have talked to QA about any special tests or cases?
"Checked in"
Does this mean everything compiles?
Does this mean it ran on the developer's machine?
Did it run on the integration machine (or in the integration environment)?
"Done" (for a task)
Does the task have implemented all the features it should?
Is everything tested?
Is everything refactored?
If the requirements don't change, would we need to modify the code?
[Does "done" mean "done"?]
"Done" (for a story)
Are all aspects of the story done?
Is the code as refactored as possible?
Is there an acceptance test?
Do all acceptance tests for this story pass?
Have we explained to the customer (or QA, etc.) how everything works?137
________________________________________________________________________
"Done" is a bit context-dependent for each project. When I work with teams to develop their definition of doneness,
we start by looking at the entire life-cycle (or value stream to use the lean term) for a feature/story in their product.
The idealistic end goal is that a feature (or actually the entire set of features targeted for a Sprint) is ready to be used
by an end user. Any part of that left incomplete at the end of a Sprint is "debt" that still needs to be paid off before
the product can actually deliver value for the users. A team may consciously decide to defer some of the doneness
for a final Sprint before release (sometimes called a stabilization Sprint, but to me that implies deferring testing,
which I don't recommend, so I usually call it a release Sprint). I suggest it is most Agile when a team defers nothing
and any Sprint can be put into use by the users immediately after the Sprint ends.
Anyway, most of the teams I've coached come up with a list that looks something like this (I'm assuming that any
preliminary analysis, design, planning that the team needs in order to schedule work into a Sprint have already been
done also note "code" covers database schemas, HTML, XML, whatever, not just programming language code):
---Doneness for a Sprint--* Code is written and clean and meets all coding standards
* Designs are clean and refactored and meet all design standards
* Code is covered by sufficient unit tests that pass locally
* Code is integrated into the code baseline
* Designs and code are reviewed per team process
* The baseline builds successfully
* All unit tests run on the integrated baseline
* Acceptance tests are written for each new feature/story
* All acceptance tests pass on the integrated baseline
* Usability testing has been done as appropriate
* The product owner has reviewed and accepted all features
* Internal documentation (i.e., design docs) is complete
137
Copyright 2000-2004, William C. Wake

http://xp123.com/xplor/xp0207a/index.shtml
84
---Sometimes left for the last release Sprint--* The product is packaged however it needs to be
* Installation and migration scripts/programs are complete
* Installation and upgrade tests run successfully
* External documentation (manuals, help files, etc.) is complete
* Training materials are done and training is ready to go
* Deployment preparation (hardware upgrades, etc.) is done
If a team is in a more formal environment, e.g., FDA regulated software, some of these items may need a formal
sign off to meet the audit requirements.
There's also the notion that all the tasks for a feature/story need to be done before the feature is done, and that a set
of features may need to be done before a release is done.
Again, this is all somewhat context-dependent, so the team needs to get together and develop their own list for their
specific product needs. It's usually an eye-opening experience when they collectively realize everything that really
needs to be complete to be "done," and how much they typically have been leaving for the last minute. Then they
understand why they are always "late!" ;-)
Paul138
CEO, Principal Consultant: Agile Logic http://www.Agilelogic.com/
________________________________________________________________________
1) Get the team in the room
2) Ask a team member to step up and be scribe
3) Ask the team "What needs to happen for a feature/requirement to get into the hands of a user?"
4) Then ask "What else?..."
5) Then ask "What else?..."
6) Generate list of the "tasks that lead to "Done"
7) Have the team decide which of these tasks belong INSIDE the Sprint and which are part of the implementation
Sprint
I led this discussion at a client's site last week and the list and level of team engagement were far more impressive
than if I'd stepped in and told the team what "Done" was (rather than have the definition originate within and among
the team). Having the definition originate with the team fosters ownership.
NOTE: Paul Hodgetts helped me think through how to lead this discussion (Thanks, Paul!) and I find it's one of the
first that any ScrumMaster or Scrum consultant should have with the development team.
138
Paul Hodgetts phodgetts@Agilelogic.com
85
Section Five:
Principles, Measurements, and Tools
86
5.1 Scrum Performance Measurements

Hi Patrick-Sorry for taking a few days to reply but I was working on exactly this question for a team this week and wanted to
have solid answers.
This team used a waterfall process from 2001-2003. I switched them to Scrum at the start of this year. They write
in Java. Here are some measurements:
Lines of code per programmer-month

Defects per thousand lines
2001-2003
389
10
2004
1206
2.9
Some code metrics as measured in Feb 2004 (2 months after Scrumming started) and today.
improvements in the code being written:
Number of packages
Number of classes
Number of methods
Lines of code
Lines per class
Methods per class
Lines per class
Cyclomatic complexity
2/04
43
718
10,451
119,950
159
14.6
10
2.3
These show
9/04
118
1,128
14,424
145,897
121
12.8
8.4
2.1
Keep in mind that things like "methods per class" going down so much means the new code written using Scrum
went down even further because the overall average is shown above, not just totals for the new code in the right
column.
Note that throughout, lines of code is "non-comment source statements". A caveat: I didn't count the JSP lines in the
2001-2003 version (not many of them as much had been migrated back into servlets) or the velocity templates in the
2004 system. If those were measured, things would look even better for the latter metrics.
I think these show a very compelling advantage to Scrum. This team became more than 300% as productive (as
measured my lines, which is somewhat questionable as a measure) and has 80% fewer defects. More importantly,
the CEO is ecstatic about what the team has achieved. They're 3x faster in lines but are probably 10x in delivering
business value. For example, the team's best programmer spent all of 2003 on a feature that has still not been used
ONCE. That doesn't happen with Scrum.
Let me know if you have any questions,
--Mike Cohn139
www.mountaingoatsoftware.com
www.userstories.com
139
From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Wednesday, September 29, 2004 at 11:13 AM
Subject: Re: Scrum Performance Measurements
87
5.2 Scrum Principles

What is absolutely necessary and what is flexible?
Scrum was originally designed to support emerging object technology environments, which have now become the
dominant paradigm in software development. One of the goals was to get the organization of the team to reflect the
potential flexibility of the software since software rigidity always reflects the organization that built it. This is a
"law" that someone came up with decades ago. Maybe someone remembers who proclaimed it.
In any event, I fell back on the argument that object-oriented languages have a set of a few interoperating principles.
Break any one of them in creating a language and many of the benefits of object technology evaporate. A similar
analogy could be made about Scrum. So here is a candidate set of principles.
Inheritance
It is easy to extend the Scrum pattern to fit the local environment without modifying the superclass represented by
the Scrum organizational pattern.
Polymorphism
The same message sent to a different Sprint can produce a result dependent on the environment.
Encapsulation
Work is packaged in increments.
Emergent Design
A small change can have a ripple effect that causes refactoring and a new design emerges.
Messaging
OO is a messaging environment. Constant high bandwidth communication works best.
Self-Organization
There is typically no "control" object. Behavior emerges from the interaction between objects in languages and
between people in Scrums.
Aggregation
Objects can be aggregated into components. Components aggregated into an architecture. Scrums can be
aggregated into Scrums of Scrums orchestrated by a metaScrum. (We may need more levels of interaction in larger
corporations.)
Reflection
Constant review and analysis at a meta-level leads to increased functionality and flexibility. This is an extremely
powerful feature missing from some languages, which tends to cripple them.
I told them not to mess with any of these aspects of Scrum.140
140
From Jeff Sutherland jeff.sutherland@computer.org; Sent: Thursday, February 10, 2005 at 3:33 PM
88
5.3 Declaration of Interdependence

Six core values emerged from our collaboration. Together, they form what we have named, "The Declaration of
Interdependence for Agile-Adaptive Management (the name Agile-Adaptive is not official at this point):
1. We increase return on investment by making continuous flow of value our focus.
2. We deliver reliable results by engaging customers in frequent interactions and shared ownership.
3. We manage uncertainty through Iterations, anticipation, and adaptation.
4. We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and
creating an environment where they can make a difference.
5. We boost performance through group accountability for results and shared responsibility for team effectiveness.
6. We improve effectiveness and reliability through situationally specific strategies, processes, and practices.
Copyright 2005
David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna
Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent MacDonald, Polyanna Pixton, Preston
Smith and Robert Wysocki.
89
5.4 Situational Ownership: Code Stewardship Revisited

I had some interesting feedback on my previous blog-entry about Code Stewardship141. Most apparent was that I
utterly failed to successfully convey what it was. Despite repeated statements that stewardship was not about code
access, it seems everyone who read it thought the code steward, as described, was basically a "gatekeeper" from
whom others must acquire some "write-token" for permission to edit a class/module.
I am at a loss for what to say other than that is not at all how it works. The code-steward serves as a mentor and
trail-guide to the knowledge in the code. Consulting the code-steward is not about getting permission, it is about
receiving knowledge and guidance:
The purpose of the protocol for consulting the code-steward is to ensure two-way communication and
learning (and foster collaboration). That communication is a dialogue rather than a mere "token"
transaction. It's not a one-way transfer of "control", but a two-way transfer of knowledge!
Perhaps I would have been better off saying more about how Peter Block142 defines stewardship in his book of the
same name (Stewardship: Choosing Service over Self-Interest, see an interesting review here143 and another one
over here144:
Stewardship is being accountable to the larger team or organization by "operating in service, rather than in
control, of those around us."
"We choose service over self-interest most powerfully when we build the capacity of the next generation to
govern themselves"
Stewardship offers a model of partnership that distributes the power of choice and resources to each
individual.
Stewardship is personal - everyone is responsible for outcomes; mutual trust is the basic building block,
and the willingness to risk and be vulnerable is a given.
Total honesty is critical. End secrecy. Give knowledge away because it is a form of power
When practiced properly, collective code ownership is in fact an ideal form of stewardship (but not the only form).
Stewardship may ultimately end-up as collective-ownership if given a sufficient period of time with the same group
of people.
However, early on I would expect stewards to have a more direct role. And I believe the form of code-ownership
that Feature-Driven Development145 (FDD) practices may seem fairly strict at first, but is really intended to be the
initial stages of code-stewardship in the first two quadrants of the situational leadership model.
I believe the form in which stewardship should manifest itself is situational, depending on the skill and motivation
of the team and its members. In Ken Blanchard's model of situational leadership146, there are four quadrants of
leadership-style147, each of which should be used on the corresponding combination of hi-lo motivation and hi-lo
skill for a given task:
Directing (hi directive + lo supportive, for "enthusiastic beginners")
Supporting (hi directive + hi supportive, for "disillusioned learners")
Coaching (lo directive + hi supportive, for "reluctant contributors")
Delegating (lo directive + lo supportive, for "peak performers")
If we apply the concepts and principles of "stewardship" using the appropriate situational leadership-style, the
outwardly visible result may appear to transition from individual code ownership, to code guardians/gate-keepers,
then code coaches/counselors, and finally to truly collective ownership.
So I would say it is the presence of stewardship, which is the key to succeeding with either individual code
ownership or collective code ownership. If stewardship is present, then both can succeed; if it is absent, it's likely
141
http://bradapp.blogspot.com/2005/03/individual-vs-collective-code.html
http://www.peterblock.com/
143
http://www.gbod.org/equipped/articles.asp?item_id=4640
144
http://www.meansbusiness.com/Leadership-and-Change-Books/Stewardship.htm
145
http://featuredrivendevelopment.org/
146
http://changingminds.org/disciplines/leadership/styles/situational_leadership_hersey_blanchard.htm
147
http://www.valdosta.edu/afrotc/pubs/notes/as300/AS300 Lsn 18 SitLead.ppt
142
90
that neither will succeed. And the collective and individual "styles" are the extreme ends of the spectrum, with
"code counselors" as the style in between those two extremes.
From: Brad Appleton at 2:04 AM

http://bradapp.blogspot.com/2005/05/situational-ownership-code-stewardship.html
91
5.5 The Top 10 Key Differences Between a Team of Individuals and a Group of Individuals
The purpose of assembling a team is to accomplish bigger goals than any that would be possible for the individual
working alone. The aim and purpose of a team is to perform, get results and achieve victory in the workplace and
marketplace.
The very best managers are those who can gather together a group of individuals and mold them into a team. Here
are ten key differentials to help you mold your people into a pro-active and productive team.
1. Understandings:
In a group, members think they are grouped together for administrative purposes only. Individuals sometimes cross
purposes with others.
In a team, members recognize their independence and understand both personal and team goals are best
accomplished with mutual support. Time is not wasted struggling over "Turf" or attempting personal gain at the
expense of others.
2. Ownership:
In a group, members tend to focus on themselves because they are not sufficiently involved in planning the unit's
objectives. They approach their job simply as a hired hand. "Castle Building" is common.
In a team, members feel a sense of ownership for their jobs and unit, because they are committed to values based
common goals, which they helped establish.
3. Creativity and Contribution:
In a group, members are told what to do rather than being asked what the best approach would be. Suggestions and
creativity are not encouraged.
In a team, members contribute to the organization's success by applying their unique talents, knowledge and
creativity to team objectives.
4. Trust:
In a group, members distrust the motives of colleagues because they do not understand the role of other members.
Expressions of opinion or disagreement are considered divisive or non-supportive.
In a team, members work in a climate of trust and are encouraged to openly express ideas, opinions, disagreements
and feelings. Questions are welcomed.
5. Common Understandings:
In a group, members are so cautious about what they say, that real understanding is not possible. Game playing may
occur and communication traps be set to catch the unwary.
In a team, members practice open and honest communication. They make an effort to understand each others point
of view.
6. Personal Development:
In a group, members receive good training but are limited in applying it to the job by the manager or other group
members.
In a team, members are encouraged to continually develop skills and apply what they learn on the job. They
perceive they have the support of the team.
7. Conflict Resolution:
In a group, members find themselves in conflict situations they do not know how to resolve. Their supervisor/leader
may put off intervention until serious damage is done, i.e. a crisis situation.
In a team, members realize conflict is a normal aspect of human interaction but they view such situations as an
opportunity for new ideas and creativity. They work to resolve conflict quickly and constructively.
8. Participative Decision Making:
In a group, members may or may not participate in decisions affecting the team. Conformity often appears more
important than positive results. Win/lose situations are common.
In a team, members participate in decisions affecting the team but understand their leader must make a final ruling
whenever the team cannot decide, or an emergency exists. Positive win/win results are the goal at all times.
92
9. Clear Leadership:
In a group, members tend to work in an unstructured environment with undetermined standards of performance.
Leaders do not walk the talk and tend to lead from behind a desk.
In a team, members work in a structured environment; they know what boundaries exist and who has final authority.
The leader sets agreed high standards of performance and he/she is respected via active, willing participation.
10. Commitment:
In a group, members are uncommitted towards excellence and personal pride. Performance levels tend to be
mediocre. Staff turnover is high because talented individuals quickly recognize that (a) personal expectations are
not being fulfilled, (b) they are not learning and growing from others and (c) they are not working with the best
people.
In a team, only those committed to excellence are hired. Prospective team members are queuing at the door to be
recruited on the basis of their high levels of hard and soft skill sets. Everyone works together in a harmonious
environment.
Submitted by Nigel Williams
93
5.6 Burndown Tracking

We are using the Excel Sprint tracking spreadsheet from DebH at wiki.Scrums.
Now we want to add a new page for the product backlog and a new chart showing the product burndown.
Note: This is not the time-boxed Sprint burndown that already exits in the spreadsheet.
Does anyone have any good links that show examples of this?
The only one I've found so far is:
http://www.mountaingoatsoftware.com/Scrum/burndown.php
but I want more, and different, examples.
Thanks for the help,
Brad.148
148
From: "w6rabbit" bwhite@inebraska.com; Sent: Wednesday November 24, 2004 at 11:16 PM

Subject: Project Burndown Chart
94
5.7 User Stories

1. A new user can register
2. A registered user can log in
3. A customer can check their bank balance
4. A customer can write a check
5. A customer can view their check register
6. A customer can change an entry in their check register
.
.
.
101. Bank system administrator can change number of logon attempts before system locks out customer
102. Bank system administrator can change how long someone is locked out for upon a lockout
103. A second bank system administrators can use same logon at same time
.
.
.
Sprint Tasks
1a. Add fields to database
1b. Code the new user user interface
1c. Write code to check for duplicate names
1d. Write code to add new user to database
95
5.8 Automated Tracking Tools

Agile Project Management Tracking Tools:
Version One http://www.versionone.net/
ScrumWorks http://www.Scrumworks.com/
Rally Software http://www.rallydevelopment.com/
96
5.9 Refactorings
Add Parameter
Change Bidirectional Association to
Unidirectional
Change Reference to Value
Change Unidirectional Association to
Bidirectional
Change Value to Reference
Collapse Hierarchy
Consolidate Conditional Expression
Consolidate Duplicate Conditional
Fragments
Convert Dynamic to Static Construction by
Gerard M. Davison
Convert Static to Dynamic Construction by
Gerard M. Davison
Decompose Conditional
Duplicate Observed Data
Eliminate Inter-Entity Bean Communication
Encapsulate Collection
Encapsulate Downcast
Encapsulate Field
Extract Class
Extract Interface
Extract Method
Extract Package by Gerard M. Davison
Extract Subclass
Extract Superclass
Form Template Method
Hide Delegate
Hide Method
Hide presentation tier-specific details from
the business tier
Inline Class
Inline Method
Inline Temp
Introduce A Controller
Introduce Assertion
Introduce Business Delegate
Introduce Explaining Variable
Introduce Foreign Method
Introduce Local Extension
Introduce Null Object
Introduce Parameter Object
Introduce Synchronizer Token
Localize Disparate Logic
Merge Session Beans
Move Business Logic to Session
Move Class by Gerard M. Davison
Move Field
Move Method
Parameterize Method
Preserve Whole Object

Pull Up Constructor Body
Pull Up Field
Pull Up Method
Push Down Field
Push Down Method
Reduce Scope of Variable by Mats
Henricson
Refactor Architecture by Tiers
Remove Assignments to Parameters
Remove Control Flag
Remove Double Negative by Ashley Frieze
and Martin Fowler
Remove Middle Man
Remove Parameter
Remove Setting Method
Rename Method
Replace Array with Object
Replace Assignment with Initialization by
Mats Henricson
Replace Conditional with Polymorphism
Replace Conditional with Visitor by Ivan
Mitrovic
Replace Constructor with Factory Method
Replace Data Value with Object
Replace Delegation with Inheritance
Replace Error Code with Exception
Replace Exception with Test
Replace Inheritance with Delegation
Replace Iteration with Recursion by Dave
Whipp
Replace Magic Number with Symbolic
Constant
Replace Method with Method Object
Replace Nested Conditional with Guard
Clauses
Replace Parameter with Explicit Methods
Replace Parameter with Method
Replace Record with Data Class
Replace Recursion with Iteration by Ivan
Mitrovic
Replace Static Variable with Parameter by
Marian Vittek
Replace Subclass with Fields
Replace Temp with Query
Replace Type Code with Class
Replace Type Code with State/Strategy
Replace Type Code with Subclasses
Reverse Conditional by Bill Murphy and
Martin Fowler
Self Encapsulate Field
97
Separate Data Access Code

Separate Query from Modifier
Split Loop by Martin Fowler
Split Temporary Variable
Substitute Algorithm
Use a Connection Pool
Wrap entities with session
From the Refactoring Home Page: http://www.refactoring.com/catalog/index.html

Maintained by Martin Fowler
98
5.10 Scrum on a Page
99

The Agile With Scrum Users Guide PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

The Agile With Scrum Users Guide PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

The Agile with Scrum Users Guide:

A Compilation of Thoughts and Practices

THE HISTORY OF AGILE SOFTWARE DEVELOPMENT ................................................ 1

4.7 TASK SIZE VS. EFFORT VS. DURATION ..................................................................................... 53

1.1 Origins of Scrum

From: Jeff Sutherland jeff.sutherland@computer.org; Sent: Sunday, December 5, 2004 at 2:07 PM

1.2 Implementation Challenges

1.3 Agile vs. Waterfall

1.4 Scrum vs. Traditional Spiral Development

<Mike Cohn agreed with Tobias. Here is a differing answer. Editor>

1.5 CMMI and Agile

Blending Agile Development Methods with CMMI, by Glen Alleman, in

1.6 Agile and PMBOK

From: "mikecottmeyer" spamhole@cottmeyer.com; Sent: Tuesday, August 01, 2006 at 9:48 AM

From: "duarte_vasco" vasco.duarte@f-secure.com; Sent: Tuesday, August 01, 2006 at 12:02 PM

1.7 Scrum with RUP

1.8 Personal Scrum

Pete Deemer petedeemer@yahoo.com

2.2 Dispersed (Non Co-located) Teams

From: "jdmcauliffe2002" jdmcauliffe2002@yahoo.com; Sent: Thursday, September 22, 2005 at 6:05 PM

2.3 On-Site Customer

3.1 Application Architecture Across Teams

3.2 Self-Organizing Teams

From: Jim Highsmith jim@jimhighsmith.com; Sent: Friday, June 3, 2005 at 4:28 PM

3.3 ScrumMaster: Elected From Team

From: "another_chriss" another_chriss@yahoo.co.uk; Sent: Monday, April 25, 2005 at 12:07 AM

3.4 ScrumMaster: Team Member or Coach

From: Paul Hodgetts phodgetts@Agilelogic.com; Sent: Sunday, January 9, 2005 at 12:50 AM

3.5 ScrumMaster: Communication

Bentley Systems, September, 2004

3.6 Business Analysts and Scrum

From: Jennitta Andrea jennitta_andrea@transcanada.com; Sent: Tuesday, November 9, 2004 at 9:46 AM

From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Tuesday, November 9, 2004 at 8:19 PM

3.7 Is the Product Owner a Pig or a Chicken?

From: Tobias Mayer tobyanon@yahoo.com

From: Dave Barrett, Lawyers' Professional Indemnity Company

From: Mike Cohn mike@mountaingoatsoftware.com; Sent: Wednesday, April 6, 2005 at 9:09 AM

3.8 Interaction During Sprint

From: Kristan Vingrys kvingrys@agentissoftware.com

From: Jukka Lindstrm jslindst@reaktor-i.com

3.9 Retrospectives: Who Should Facilitate

From: "gabby_robertson" gabby_robertson@yahoo.com; Sent: Monday, May 16, 2005 at 5:26 PM

3.10 Sprint Review: Stakeholders Role

From: Ken DeLong ken.delong@valtech.com; Sent: Tuesday, February 8, 2005 at 5:55 PM

From: Andreas Schliep andreas.schliep@web.de; Sent: Wednesday, February 9, 2005 at 7:51 AM

3.11 Team Members

3.12 Performance Reviews

From: Jim York jim.york@ccpace.com

4.1 Best Practices

4.2 Implementing Agile on Your Own

4.3 Daily Builds

Paul Hodgetts phodgetts@Agilelogic.com

4.4 Daily Scrum Meeting

From: Mike Beedle beedlem@e-architects.com

4.5 Scrum of Scrums

From: "dtrowern" dtrowern@aol.com

4.6 Sprint Goal

4.7 Task Size vs. Effort vs. Duration

4.8 Task Size (Breaking Down Tasks)

4.9 Sprint Calendar

4.11 Estimating Testing

4.12 Planning and Estimating Tasks

4.13 Technical Debt Big Refactorings Not Yet Done