Re: [scrumdevelopment] Re: More points or "slower" progress?
- Hi Steve,I think the stakeholder thing thing stems from the fact that we've never really had enough conversations with them about how to monitor and understand progress. Consider this...Before project has really commencedTeam: "We've identified 50 stories and they total 300 points worth of work. We know from past experience that this team manages about 25 points every two week sprint, so expect this to take about 6 months."Stakeholders: "Sounds good. Looking forward to it."After sprint 1Team: "OK we did good and kept up our usual velocity, got the following features done..."Stakeholders: "Cool, so we're on track?Just 275 points worth of features to go?"Team: "Well in the course of sprint 1 we uncovered some details that have led us to add a few more stories in. In fact we added in about 20 points worth of new stories."Stakeholders: "Hmm..."Repeat that for a few sprints. It works OK. And people can and do understand what's occurring. Some better than others. That's part of what got me thinking about this. If something we discovered was just part of what the story was trying to describe anyway (e.g. handling large JPGs in my case) is there any real benefit to pushing it off, adding another story to cover that work, estimating, prioritizing and tracking it? Seems like it behooves any team to make sure the "discovered" details are truly needed before just blindly implementing them, but if they are, why create a new story for it? If on the other hand they're more nice to have then by all means defer, create a story and prioritize accordingly.JonOn Mon, Jun 6, 2011 at 6:01 PM, Steve <steve@...> wrote:
Bit curious as to your stakeholder comment about 'remaining points to first release keeping jumping about'
If you are working in fixed time, then the points to Release should remain constant (given 'constant velocity), just the features/PBI/Stories that vary.
Ah,but I guess if you have been varying velocity rather than adding feature/PBI/Story then the points to release would vary.
Still say that adding a feature/PBI/Story to PB with appropriate priority and points estimate focuses communication on what is important - 'what are we likely to be getting at release'
--- In firstname.lastname@example.org, Jon Archer <jon@...> wrote:
> Hi Adam,
> Just to clarify -- not a web app, nothing to do with uploads going on here.
> What we have is perhaps most easily thought of as a specialized image editor
> app. Think Photoshop for clinical studies handling MRIs, CTs, X-rays
> etc.It's also replacing an existing legacy application.
> So, for question #1, the expectation was that when folks look at JPGs in the
> app they will be able to do so without issue. Just like they could in the
> old app. I'm not sure most of the folks involved would have thought to
> comment on typical file sizes and if I recall rightly the developers just
> went "uhuh" because, well, opening JPGs is a piece of cake, right? Often if
> we get some more specialized sounding feature request we will indeed ask for
> a selection of typical image data so we can check for things like this. On
> this occasion we just got caught out I think.
> 2. Yes this is where things emerged. The usual batch of test JPGs was used
> for testing and BAM...out of memory problems galore.
> 3. I reckon it's 'c' because, subsequently, a more sophisticated approach
> has been implemented (using memory mapped files, thus:
> This whole episode though got me thinking about features vs. stories and
> when to add new stories vs. "suck it up" because that was what was meant for
> a story anyway. That and one of our stakeholders commented last week that
> the number of points left to complete the first release kept bouncing around
> and this was confusing to him.
> I do believe after writing things down, seeing people's comments (thanks
> all) and thinking some more that the real answer is "it depends" and
> "communicate more" to make sure you do the best thing.
>> On Mon, Jun 6, 2011 at 4:14 PM, Adam Sroka <adam.sroka@...> wrote:
> > A couple questions:
> > 1) Obviously, there is an expectation that the application handle a certain
> > number of simultaneous uploads of a give file size. Were these expectations
> > known ahead of the initial implementation? What is the basis for these
> > expectations?
> > 2) If you knew of the expectations before implementing, did you test for
> > them before declaring the story done? Otherwise, what did you test for
> > before declaring the story done?
> > 3) Which of the following would you say was the /most/ significant
> > contributor to the failure?
> > a. lack of clear expectations
> > b. lack of testing for known expectations
> > c. poor technical decisions given the information available at the time
> > d. something else (please explain)
> > Thanks,
> > Adam
> >> > On Mon, Jun 6, 2011 at 7:49 AM, Jon Archer <jon@...> wrote:
> >> Hi all,
> >> I'm curious whether anyone has comments, advice etc. on the following...
> >> My team is working on a new product. We started off with a big list of
> >> features and did some approximate estimation in story points coming out at
> >> around 300 points for the desired 1.0 release feature set. After
> >> establishing a fairly stable velocity (~25 pts/2 week sprint) we projected
> >> that release 1.0 would take about six months.
> >> As we work through implementing these features we sometimes find one is
> >> more involved than we anticipated. For example, last sprint we had a story
> >> to add support for opening JPG files. While the story was completed in
> >> essence, and certainly by the acceptance criteria defined, we found that
> >> opening many large JPG files created an out of memory situation.
> >> So then the question arises: is handling this situation a new story?
> >> If we add in a new story to handle this, we estimate it and so our total
> >> number of points to complete the 1.0 release increases (even if by only say
> >> 2 or 3 points, although do this with a story or two every sprint and we
> >> start to slide away from our original 300 point estimate.) Taking this "add
> >> stories when the feature is more involved than anticipated" approach allows
> >> us to maintain our 25 pts/sprint velocity and the stakeholders can see the
> >> amount of work we originally anticipated growing ("there's more than we
> >> originally thought there was").
> >> The other approach is to say, "well handling large JPGs was clearly
> >> implied as part of the original feature, we should just make that work".
> >> Taking this approach our original estimate of 300 points doesn't alter, but
> >> our velocity probably drops as we find the occasional story spills over to
> >> the next sprint and we have to finish up the additional stuff we
> >> discovered.
> >> It seems to me that either approach is OK -- the main thing we care about
> >> is our ability to continue to predict when 1.0 will be released, and either
> >> approach will enable that. Considering each approach I see pros and cons for
> >> both, but I find myself more drawn to the "let's not add another story"
> >> approach since what is needed was clearly implied by the original one
> >> anyway. This just seems simpler to me. Here's my pros and cons below.
> >> What do folks think? Perhaps I am obsessing over something that doesn't
> >> really matter :-) but I'm still curious. We can't be the first team to
> >> debate this...
> >> Adding a story, pros:
> >> - stakeholders can see the amount of work we original imagined was
> >> involved has grown and more have more chance to comment on necessity of such
> >> - it probably shouldn't matter, but velocity remains stable and nobody
> >> feels the need to cross-examine the team and ask "why has your velocity
> >> dropped?"
> >> Adding a story, cons:
> >> - it probably shouldn't matter, but there's likely a class of stakeholder
> >> that will question why all this "extra" work is emerging and ask how come we
> >> failed to identify it in the first place
> >> - it's another thing to enter track (and we have the pleasure of using a
> >> popular agile lifecycle management tool that makes that more overhead than
> >> anyone on the team would like -- alas hard to drop this as the team is
> >> distributed geographically)
> >> - number of points to complete release 1.0 keeps growing making (a certain
> >> class of) stakeholders anxious that "we don't know how much work is left to
> >> do, how can we ever hope to get to the end of it?"
> >> Not adding a story, pros:
> >> - Nothing extra to track (though we may update the acceptance criteria of
> >> the original story)
> >> - Number of points to complete original feature set for 1.0 release
> >> remains the same (unless we discover a need for genuinely new feature)
> >> Not adding a story, cons:
> >> - the potential roasting of the scrum master/team as a whole -- "why is
> >> the team's velocity dropping?"
- agreedOn Thu, Jun 9, 2011 at 1:24 PM, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:Thanks Jack.In re-reading my advice, I want to clarify that what I described is for a scenario where there was no story test or requirement defined up front for the particular issue. If there was a story test or known requirement in a scenario like that(i.e. partially finished story), then I would recommend Mike Cohn's advice that I pasted into my other post.Weird corner cases, almost all of which are solved with good ATDD and slicing stories small.-------
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
From: JackM <jack@...>
Sent: Thursday, June 9, 2011 9:50 AM
Subject: [scrumdevelopment] Re: More points or "slower" progress?------------------------------------
Excellent advice Charles!
--- In email@example.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
> My preference on these kinds of things is as follows:
> 1. Story tests are defined (at least at a high level, but preferably at a detailed level ) before the story is taken into a Sprint.
> 2. If there is no story test(acceptance criteria) that clearly covers the problem, then there is no bug. If the team feels like one of their story tests does cover the problem, then it is a bug.
> 3. If there is no bug and the behavior is unacceptable, then that means it's a new story.
> My position on this is kind of hard line for these reasons:
> 1. It teaches the Scrum team to look closer for requirements and story tests, and pay more attention to those kinds of requirements(story tests) in the future. The PO is *not* the only person who is responsible for identifying story tests -- it should be a collaboration among the entire Scrum team.
> 2. It makes these kinds of issues more visible. A new story with a size and new story tests is more visible than a small hit to velocity and a couple of new tasks. Velocity's primary purpose is to predict release dates, and the new story will affect the release date(and/or scope) appropriately. (Taking a velocity hit would also affect the release data/scope appropriately too of course)
> Some things to consider going forward:
> 1. Pay more attention to non functional requirements(NFR's), especially as they compare to the existing systems.
> 2. Consider describing these NFR's more explicitly with constraints/numbers. For instance, is it ok for
> someone to open a 2 terabyte JPEG? Probably not... but you need to set
> that maximum bound somewhere.
> 3. Consider having discussions
> earlier in the sprint (ideally before the sprint in a backlog grooming
> session) about how you will test the story. Define your story tests *before* beginning development on the story. That may or may not have detected
> the problem in this case, but it will almost certainly help in the
> 4. The "old system" can almost be
> treated as "legacy code" (or "legacy requirements") in the new system.
> Both the business people and technical people should pay more attention
> to knowing the old system better.
> I noticed some other bad smells in the OP's emails... Stakeholders who don't understand why points in a release change and someone who "roasts" the team for a velocity change. Whoever does that roasting doesn't know diddly about Scrum. Both of these are impediments that need resolving.
> Charles Bradley, CSM, PSM I
> Experienced Scrum Coach
> My blog: http://scrumcrazy.wordpress.com/
> >From: jamesjhawkins <jhawkins@...>
> >To: firstname.lastname@example.org
> >Sent: Tuesday, June 7, 2011 9:30 AM
> >Subject: [scrumdevelopment] Re: More points or "slower" progress?
> >I agree with your decision to reduce velocity.
> >What seals it is the explanation that the old software that you're replacing handled large images no problem. Sorry if I misunderstood, but that seems to make large-image handling a must-have not a nice-to-have.
> >1. Communication is always the problem
> >I've heard communication blamed so often that I now doubt the validity of that blame.
> >It seems to me that the statement "communication is always the problem" has the same utility as the statement "communication is never the problem".
> >2. Capacity requirements
> >According to Gilb, I believe, capacity (and performance) requirements are generally the worst analysed. So, don't feel too bad that this capacity requirement was missed.
> >3. Ideal play-out
> >In my opinion, what should have happened is that the product owner should have:
> >3.1 Been aware that the new software had to do whatever the old software did, and
> >3.2 Been aware that there was a standard set of test data, utilised by the old software, and
> >3.3 Written a user story like "As a user of the new product, I want to handle data that I could handle in the old product" with a reference to the standard test data set in the completions part.
> >That might have led to a higher estimate, which in this case would have been more accurate.
> >Cheers, Jim
> >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:
Web Site: www.agilebuddy.com