Avi, ... In normal sprints, there will still be activities toward improving the development environment, doing spikes to answer some question, grooming theMessage 1 of 61 , May 25, 2011View SourceAvi,
On 5/25/11 2:56 AM, avi_a@... wrote:
> Thanks George, quite an eye opener!
> I'd definitely like to try this the next time the chance comes up.
> Of course until I've tried it it wouldn't be right to criticize,
> nevertheless I do feel some concerns come to mind:
> One of the strengths of "normal" sprints is that the team has full
> focus solely on the story at hand. I'm wondering if in this kind of
> Sprint1 they wouldn't be distracted by the preparatory activities
> going on (refining the rest of the backlog, getting the estimates in,
> doing spikes etc). I'm almost tempted to view this as multitasking
> which impedes performance. But on the other hand I can see the team
> working on a spike just like any other PBI, with full focus etc.
> Estimating - as you wrote - can also be treated as a sprint task with
> the estimates being the deliverable. And backlog-building is a PO
> activity anyway, the team should not be extremely distracted by it.
> So maybe this is not an issue.
In "normal" sprints, there will still be activities toward improving the
development environment, doing spikes to answer some question, grooming
the backlog.... There should be proportionally less as the project gets
moving, but it'll still be there. My caution is to not let these things
consume a whole sprint, or be done in absence of working toward business
I don't recommend treating estimating as a sprint task. It's just
overhead. Do as little as you can. Remember the primary focus of
estimating is choosing the amount of work that can fit in a sprint. A
team can learn to do that without estimating the stories. The secondary
focus of estimating is predicting how much will be done by when. Work
in larger chunks with less precision for that. And just watch to see if
the progress moves toward that goal.
And building the backlog is lead by the PO, but the whole team should be
involved. Don't let the backlog be where the business throws
requirements "over the wall" to the development team. It's a joint effort.
> Another concern that pops to mind - As I understand what you wrote,
> you start by picking any story that comes to mind and can be achieved
> regardless of what other stories might be required later on, this for
> the sake of delivering something at the end of the sprint. Is
> delivering a working increment - //any// increment regardless of it's
> relative value compared to other stories - really worth it? Is
> delivering at all costs really a goal for itself, even if we're not
> sure the delivered story is the most valuable or that is the most
> likely to reduce risk?
I don't say /any/ story (though you could probably make that work); I
say the most obvious story. What is this system about at its core?
Choosing something that expresses the core, as thinly and as thoroughly
from end to end as possible, is best. Or make this choice the best you
can. It doesn't have to be perfect. And it's not really that hard
except in the most ill-conceived of projects.
> The alternative of course is to do "sprint0" (or an otherwise named
> preparatory activity) before "starting", which means deferring
> delivery for sake of delivering the most valuable things first.
> As far as splitting stories - Yes, I'm quite familiar with the
> techniques you wrote about. I agree with you that they can be applied
> "on the fly" and just-in-time when the need arises.
> Another though regarding the value of estimates - In my experience
> one of the most (if not the most) valuable estimate is the question
> mark - identifying upfront what the team can't estimate means an
> early identification of uncertainty and risk. Once these
> "unestimatable" stories are identified I usually like to start with
> them first, or to identify spikes that might help "put a number" on
> them so as to eliminate the risk as early as possible (a-la Mike
> Cohen's risk/value technique). So that is one good reason to want to
> do the estimates first and not delay them, although like was
> previously stated - this might be possible during a
> product-delivering sprint1.
To me, stories that have unknowns seem to fall into two camps: those
where the details of the story are unknown (and we can't describe clear
examples of it) and those where we don't know how to accomplish it
(where we might want to do some research or a spike to figure that out).
Sometimes it's appropriate to put risk first. Sometimes the risk
isn't all that great or the story is low enough priority that it's worth
living with the risk. It's a judgment call, and no rule is going to
Whatever you do, you don't want to estimate the entire backlog before
starting. Things will change and things will be learned along the way.
You want to get benefit from these facts, not waste. So you're always
going to have unknowns pop up through the project.
> These concerns are just me thinking out loud, not necessarily
> criticizing or defending any specific answer. I'm curious as to what
> you and others think about it.
> And like I wrote above - definitely worth giving a try. It might
> change some core beliefs and viewpoints of mine as to how to get
> things done.
Good luck with it. I'd be happy to hear your experiences as you try
this. I expanded my email on my blog:
free to comment there.
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
Agreed, with the caveat that a team should strive for the minimum amount of documentation that could possibly work. ... Charles Bradley, CSM, PSM IMessage 61 of 61 , Jun 9, 2011View SourceAgreed, with the caveat that a team should strive for "the minimum amount of documentation that could possibly work."-------
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
From: JackM <jack@...>
Sent: Thursday, June 9, 2011 11:41 AM
Subject: [scrumdevelopment] Re: Sprint deliverables
However I'd like to comment if the team determines that some documentation is required then by all means produce the required documentation as part of the Sprint deliverables. I wouldn't put a focus on documentation though but that doesn't mean No documents.
--- In firstname.lastname@example.org, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
> > If you are in the requirements business, then you need to ship a
> > draft of the complete requirements, not just chapter one. But if the
> > product is software, ship software.
> I'm not a big fan of trying to apply Scrum to other disciplines than software,
> but I don't think you have your analogy correct here.
> If requirements is your product, then you need to ship something more than a
> draft. You need to ship a "done increment" of your requirements. I'm not sure
> how the chapter metaphor applies to requirements. This is one of the major
> problems with applying Scrum to things other than software development... the
> principles don't always translate easily or even at all.
> Charles Bradley, CSM, PSM I
> Experienced Scrum Coach
> My blog: http://scrumcrazy.wordpress.com/
> From: Ron Jeffries <ronjeffries@...>
> To: email@example.com
> Sent: Fri, May 20, 2011 5:01:32 AM
> Subject: Re: [scrumdevelopment] Sprint deliverables
> Hello, poojawandile. On Friday, May 20, 2011, at 3:37:01 AM, you
> > hi, We have a debate going on in our company. Some Scrum teams are firm
> > believers that increamental shippable product at the end of the sprint
> > is what should be the sprint deliverable. The other section believs that
> > a design document, a requriemebnts document cud also be the sprint
> > deliverable, especially when the project is new and it needs to work on
> > the requreiments doc and design doc before coding can start. Can a req
> > doc or a design doc be a sprint deliverable?
> Scrum asks for a potentially shippable increment of product. If your
> product is software, that means software, yes even in the first
> If you are in the requirements business, then you need to ship a
> draft of the complete requirements, not just chapter one. But if the
> product is software, ship software.
> Ron Jeffries
> The central "e" in "Jeffries" is silent ... and invisible.
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@...! Groups Links
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
<*> To visit your group on the web, go to:
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to: