RE: [scrumdevelopment] Re: Sprint Demo Review of back-end platform work
Thank you all for your input. The “demo” went extremely well, however the audience was primarily the engineering team and the product owner. Stakeholders were not present for this demo which actually helped keep the review on-track. Each developer gave in-depth details on the functionality they implemented and provided examples with their unit tests.
Overall I would call this review a success because it enabled the whole team to discuss the architecture on a much deeper level and provided confidence in each other that their teamwork was well executed.
Thanks again for all of your viewpoints, it really helped!
Well??? How did itgo?
Sent via BlackBerry by AT&T
From: "David Goodman" <david.goodman@...>
Date: Fri, 5 Sep 2008 13:50:19 -0700
Subject: RE: [scrumdevelopment] Re: Sprint Demo Review of back-end platform work
Wish me luck, I’m executing in 10….. J
--- In email@example.com, "woynam" <woyna@...> wrote:
> --- In firstname.lastname@example.org,
> > Ron,
> > I get why you made your comment of "Don't do that" and I
> > how it applies to cases where features are broken up horizontallydon't
> > rather then vertically. But I don't think that's the whole story.
> > Knowing your penchant for examples, I offer you two types of system
> > from my experience that fit David's description of features that
> > provide easily visible value. The "features" are verticalwithin their
> > systems and deliver the value they are meant to deliver. I'd like tosystem
> > understand if you still somehow argue that they shouldn't be built in
> > that way.
> > 1. Scalability (and other non-functional requirements)- "Your
> > worked great last sprint. Now show me the same thing, but with100,000
> > simultaneous users this time." Do we not take non-functionalYes, I'm of course familiar with that construct. But consider what
> > requirements and turn them into Product Backlog items? It's not an
> > easy thing to make this an exciting demo, but there is great value to
> > the business in providing it.
> No, you don't have to take non-functional requirements and turn them
> into PB items. Non-functional requires always affects a functional
> requirement. If you add the functional requirement, i.e.
> story/feature, to the backlog, along with the impact of the
> non-functional requirement, you'll have something to demo.
> For example, "As a user, I want to enter an order and have it respond
> within 2 milliseconds while the system is supporting 100,000 users."
> The tasks that address the internals of the system are associated with
> the feature, so you're always addressing something that provides
> business value. If no story is affected by the non-functional
> requirement, then why would you do it?
happens when you only built the system for 1000 users and the
unthinkable happened...you got successful beyond your wildest dreams.
Now all of a sudden you need to add no new features but a lot of load
handling capability. That makes it a story for me, since the team will
be doing nothing else until the system can handle the new load. And I
can guarantee that there will be anxious executives who really want to
see a demo when you claim you're done. At least at my company.
> > 2. Common (i.e., meant to be shared) back-end capabilities such as
> > throttling systems, caching systems, storage systems, or messaging
> > systems to name a few. The customers of these systems are often the
> > builders of other systems. What these systems do tends to be quite
> > invisible, in demo terms. The features of these systems are accessed
> > by their users via API calls or messages. Again, tough to demo, no?
> > Yet these systems have external, paying customers.
> > I've had to try to demo things like these, and it's hard. But it
> > doesn't mean that there is no value there, and I fail to see that
> > some kind of agile party foul to build them. If it is, then I'd likeYes I get that too. Now put yourself into the position of being a
> > to understand a better way to think about this.
> Don't these things affect some feature of the system? Why do we cache?
> To speed things up. OK, so demo a feature with and without the cache
> to show how it speeds things up. If the PO yawns, then it must have
> not been a high-priority item to begin with.
separate company that just builds caches. you need to release a fully
production-ready cache to your customers. They will pay to use it and
be happy. They are your customers. Before they see your product, you
will complete a sprint and need to demo the cache to your own company
(and maybe some potential customers also). So what do you do? You find
ways to build a non-boring demo of the cache. That's all this
discussion is about, right? The original question was about building
compelling demos of back-end functionality that often does not demo in
an exciting way.
> The other important aspect about always (trying to) tying things to
> features is that it demonstrates that the software is always ready for
> prime time. If you build specific components to address non-functional
> requirements, but you don't integrate and test them in the real
> software, then you really don't know if it's going to have the desired
> I've seen plenty of cases where folks spent a great deal of time
> building the next greatest thing, and when they finally plugged it
> into the actual application, it didn't have the desired affect. In
> many cases it was because there were other bottlenecks that were
> bigger, or hidden.
> > Thanks.
> > alan
> > --- In email@example.com,
> > <ronjeffries@> wrote:you
> > >
> > > Hello, David. On Wednesday, September 3, 2008, at 2:13:34 PM,
> > > wrote:best way
> > >
> > > > Hello, I wanted to get some input from the group on the
> > to runcomponents
> > > > a Sprint Demo Review where strictly back-end platform
> wereThere are
> > > > developed and there is nothing customer-facing to demo.
> > manydocuments,
> > > > options, such as running unit tests, going over design
> > > > possibly powerpoint presentations, etc, but I am not surewhat
> > > > best.that".
> > >
> > > Well, hmm. I fear that the right answer may be "Don't do
> > >developers
> > > Did the Product Owner specify acceptance tests?
> > >
> > > Did the Product Owner actually /ask/ for this? Or did the
> > > plan this Sprint? If the latter, the P.O. should refuse to pay.:)
> > >is
> > > Really. I know you don't like this answer, but what works best
> > > "Don't do that". Second best is far behind. I guessI'd tell 'em
> > > what was done and run the unit tests. But really ... if we don'tdo
> > > something with business value, why should we get paid?
> > >
> > > Ron Jeffries
> > > www.XProgramming.com
> > > Anyone can make the simple complicated.
> > > Creativity is making the complicated simple. -- Charles Mingus
> > >
Big Fish Games, Inc. A New Game Every Day!™