Re: [scrumdevelopment] Re: Sprint deliverables
- Of course, all work being done is in the form of PBIs, unless it's a time-boxed part of the process, like a grooming meeting that happens every sprint. I think that doing *any* production story at all proves that the Team can actually build product - that the process works - and this is the best product of all in the first sprint. What is more valuable than proving that the team actually works? What is more valuable than proving that the team understands the problem? what is more valuable than trying to get a handle on how much effort the release will take? etc? Remember that not all value is deliverable value to users of your system, the PO's job is maximize value of all types - to compare apples to oranges - and do what is best for the organization and team... it's a tough gig. Dan ;-)
On 5/24/2011 11:56 PM, 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.
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?
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.
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.
--- In email@example.com, George Dinwiddie <lists@...> wrote:
> Hi, Avi,
> On 5/22/11 1:30 AM, avi_a@... wrote:
> > Michael,
> > --- Michael James<mj4scrum@> wrote:
> >> ...This "Sprint 0" mutation we sometimes hear about is a reversion
> >> to waterfall habits, reflecting reduced skill, and reduced alignment
> >> with lean principles.
> > What do you do if the team doesn't know enough to start estimating or
> > delivering?
> I've found that this isn't such a big impediment if you borrow from the
> lean point of view. Start with asking yourself, "what would it take to
> start delivering?" (Forget the estimating, for the moment. Estimates
> are a deliverable.) I find it goes something like this:
> > in fact, when do you write the initial backlog and do the
> > initial estimation?
> The initial backlog really only needs to be one item in order to start
> delivering. If you've got too many unknowns, then just start with one
> item. Get the PO, the programmers, the testers, and anyone else who
> needs to be in on the discussion (UX? Ops?) to talks about it. (I call
> this a meeting of the Three Amigos.) What is the one obvious thing that
> needs to be done? I can't imagine a situation where a project is
> started without any ideas at all.
> Take that one thing, and slice it into thinner slices. Decide on the
> examples that represent acceptance of those slices. Some of the slices
> will have questions that can't be answered. Put those aside for the
> moment. Choose the most central slice that travels through the entire
> concept from end to end, or as close to that as possible. Estimate that
> as one team-sprint. (Estimates don't have to be "right." They're just
> estimates.) Start building it.
> If you can't accomplish this slice in one sprint, it's not thin enough.
> See http://blog.gdinwiddie.com/2011/05/01/splitting-user-stories/ and
> try again.
> If you get this slice done before the end of the sprint, then pull in
> another slice. Estimate this as "the rest of the sprint." Repeat as
> needed. As long as you've gotten one slice done, you've got a
> potentially deliverable product increment.
> > when do you do initial release planning? during
> > sprint1 planning? if so, how long does this meeting take you? (a
> > whole day? several days?)
> Unless you think you can release after one or two sprints, there's no
> rush on initial release planning. And I can't imagine thinking you can
> release that early if you have so little information.
> During the first sprint, refine the backlog. When you think you've got
> enough information about what needs to be done, then consider the
> initial release plan. By then you'll also have accumulated a little
> information about how fast things get done. See, also,
> Sure, there will still be a lot of holes in your knowledge of what needs
> to be done and how fast things get done. Don't trust your initial
> release plan to be "right." It's just a stick in the sand to help you
> judge how things are going. Keep planning, and move the stick as needed.
> This sort of beginning is very like the Hudson Bay Start that Johanna
> Rothman describes in her book, Manage It [http://amzn.to/jbA4k9 pp.
> 52-53]. There's really no reason (other than "that's not the way we do
> things around here") that this can't work for the start of any team/project.
> - George
> * 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 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: