I'm the scrummaster of a software engineering team that creates, updates and
maintains production software used to generate data-products.  We want to work
on a better nightly build environment with a lot more QC on the data-products,
but the backlog that is maintained by our product owner is bigger than what can
be planned in during the next sprints.  That's why that our QC-improvement
stories are postponed without a real guarantee when we will be able to work on. 
As a team, we are convinced that the added value after 2 or 3 sprints will be
that big that our velocity will increase significantly.  Is it possible, as a
scrumteam, to plan in our own stories, even if the product owner disagrees?

Hello, Paul.  On Wednesday, April 1, 2009, at 3:44:17 AM, you
wrote:

> Is it possible, as a scrumteam, to plan in our own stories, even
> if the product owner disagrees?

Possible, certainly. Consequences don't seem good.

Can you improve the build incrementally, as part of each story?

> but the backlog that is maintained by our product owner is bigger
> than what can be planned in during the next sprints.

It's supposed to be. It is the sole job of the PO to choose stories
to get the best product done by the date, at the speed the
developers can accomplish.

It is worth noting that higher speed would get more stories done.
Can you honestly offer higher speed for some investment? How much?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Attend our CSM Plus Course!
http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
New and stirring things are belittled because if they are not belittled,
the humiliating question arises, "Why then are you not taking part in
them?"   -- H. G. Wells

the ScrumMaster's duties to the Product Owner are more clearly defined and limited in scope. Rather than "putting fires out," the ScrumMaster's support work with the Product Owner tends to be more easily anticipated and performed on a regular, ongoing basis. In essence, this work can be summarized as assisting the Product Owner with various preparatory activities. These often include updating the Product Owner about the team's progress and successes, assisting in the preparation of the backlog for sprint planning (also known as backlog grooming), and radiating important status updates to all team members and stakeholders.

In many ways, the ScrumMaster's role in regard to the Product Owner can be seen as a kind of liaison for the team, reinforcing its communication with the Product Owner. As such, he or she is an essential hub for communication, working to make sure that everyone involved in the project is on the same page.

My 2 cents:

First off, in saying the PO is "OK" with all of these things...are the C-level
folks OK with it? More likely, they're not aware of it. Are shippable product
increments being released after each Sprint? If not, the consequences of not
producing will come home to roost, sooner or later.

I'll break down the problems you note and answer each:

"Do they no longer need retrospectives?  Do they no longer need a ScrumMaster?"
---IF they are going to do Scrum, they need both. Scrum has a minimum of
roles/artifacts/ceremonies, and they need to be respected to be doing Scrum.
Within that, though, the team can self-norm.

"I see they have distractions...They work on stuff outside the project"
---These can be examples of things that effect your velocity. In my opinion,
they probably should be impediments, but it seems this team and PO don't see
them as keeping them from completing work, but more as part of the territory. As
such, you should remove that time from your planning as overhead to reduce the
amount of "productive" time the team will commit to for a sprint.

"they don't finish most of the stories in an iteration...but 80% of the stories
are 80-90% done"
---Depends on the definition of "done" you're using. Is "done" shippable and
releasable? If so, what's the 10-20% of "done" they're not completing? I think
you either need to adjust the definition of "done" or get clear with the PO
about the ramifications of not releasing product.

"they pull in other stories mid iteration w/o first talking to the rest of the
team and sometimes the PO and yes...they and PO are all comfortable with that
too"
---Are these different than the other things you mention them pulling in above?
If so, this is a clear problem if it's being done unilaterally by one team
member, because it's changing what the TEAM is committed to. I understand the PO
is OK with it, but this one you have to curb.

Having said all that, I agree with what others have posted that you can't force
the change as ScrumMaster. What's the old saying about how many psychologists it
takes to change a lightbulb? One, but the lightbulb has to *want* to change. The
same can be said of organizations adopting Scrum, or any organizational change.
Also, people will do more to avoid pain than they ever will to gain pleasure. If
the team is not shipping product, and there are no consequences, you are
fighting an uphill battle against the organizational culture.

Have a heart to heart (NON-confrontational!) with the PO. See if the PO, and the
team, can sign on to doing one light Sprint following the framework. Benchmark
compare the success to what you've been seeing previously. If you can show them
that they can produce more, and their daily experience can be better, you can
get them to sign on to really doing Scrum.

I do not believe that have a team of generalists is a tenet of Scrum. As
originally defined, Scrum only required a cross-functional team capable of
delivering completed software at the end of the Sprint. The team could be
composed of generalists, or it could be composed of a group of specialists.

Now, I certainly believe that a team of generalists is preferable to a team of
specialists, but that besides the point.

On the last project I worked on we had dedicated testers working on the team.
Their job is primarily to flush out the multitude of scenarios that fall outside
the happy path.

In one case it was quite amazing. A feature that was roughly described in one
paragraph resulted in a test suite comprised of roughly 130+ test cases. The
suite required ~75 pages of text to print out.

Mark


--- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
>
>
> The emphasis on collaborative activities here is good, and should be the main
lesson to be taken from this discussion. But in a Scrum development activity
would there still be 'testers', whose sole job presumably is testing? Similarly,
techwriters. I can understand about techwritiers, if their job is the
development of user manuals and technical manuals, which will probably be
developed after the development has been done. I think the phrase 'developers,
analysts, testers, techwriters' is inappropriate inasmuch as there would not be
developers AND analysts AND testers; that ignores one of the characteristics of
the Scrum team which is that each developer is an
analyst/designer/programmer/tester/database architect rolled into one.
Presumably each developer may have more skill strength in certain areas than
others, but that does not mean specialist analysts etc.
>
>
>
> The 'iteration as mini-waterfall' concept is just a reflection on this
function specialisation. I think one aspect of this is that in a one week or two
week sprint, there is just no time for anyone to be sitting around waiting for
someone else to finish their 'phase'. Clearly once members of the team have
taken on some development work, then they will undertake the whole range of
development activities in parallel, not in a serial fashion, to achieve the
development outcomes required.
>
>
>
> Where I do think specialisation will and probably should occur is in
activities such as DBA functions where database efficiency is part of the job,
and is ongoing. (But this does not imply changes to the 'external' schema of the
database).
>
>
>
> But ... collaboration rules! If it doesn't, there is a problem.
>
>
>
> And the subject of testing in all its aspects is clearly of great importance
in this. Adoption of iterative development and many other aspects of such
development is relatively easy, and certainly easy to understand even if not
accepted. But testing is the nub, I believe. Test first, test driven
development, continuous integration etc. should be foremost in any training and
education I believe.
>
>
>
> Regards,
>
> Roy Morien
>
>
>
> To: scrumdevelopment@yahoogroups.com
> From: kcsarath@...
> Date: Thu, 26 Mar 2009 07:59:11 +0530
> Subject: Re: [scrumdevelopment] Tester in Scrum Team: how do you involve
testers into estimation?
>
>
>
>
>
> Hi Joe,
>       There are two time when the team gets together for estimations.
>
> 1. User Story estimates - which are done in story points, to set up a long
term road map for the project and give a high level perspective about the
release time lines based on the total story points and the velocity.
>
> 2. The team picks up  sub set of the stories for a sprint (The sprint planning
session on the first day of the sprint) Where the team gets together to identify
tasks to get the stories complete during the sprint and typically estimate the
tasks in hours.
>
> In the first case when the whole team comes up with story point estimates
(using planning poker) every one tries to estimate the size of the story based
on their perceived effort. So developers, Analysts, testers, tech writers are
all expected to estimate for the whole effort. Obviously this is counter
intuitive for most teams at the start of their scrum transitions and leads to
questions like "How can i as a tester estimate for dev effort sizing,  and vice
versa" But what i have seen with teams that i coach is that over time testers
tend to appreciate the dev effort at a ball park level and developers start
doing the same for the testing and other activities. So over time the whole team
gets to understand the whole effort to get a User story to completion.
>
> Most teams are expected to define a DONE critera for user stories, and this
could include regression through automation, system testing, etc. to be done
within the sprint. If that is not possible some time teams allocate specific
time in Stabilization sprints at regular intervals to take care of regression or
system testing debt.
>
>
> Involving the testers and tech writers during this estimation actually is very
important because the developers tend to appreciate the effort in getting the
whole story done which includes testing and documentation, etc.
>
> I am not sure which books you are referring to, but i would prefer that the
team doesnot have specific member specific backlogs. It is always better to get
the whole team see the same goals and perspectives.
>
> Comments and brick bats welcome ;-)
>
>
> thanks,
> Sarath.
> CSP.
>
>
> On Thu, Mar 26, 2009 at 6:59 AM, jykojin <jykojin@...> wrote:
>
>
>
>
>
>
> Hello All,
>
> I have a question:
> When we have scrum planning meeting and play card game to estimate the story
point, will tester also play cards for estimation?
>
> How do you estimate the system testing effort in scrum team?
>
> Some books say that we can make a tech-backlog which contains something
related to tech or engineer. Do you use this way normally?
>
> Is there any experience you can share?
>
> Thanks,
> Joe
>
>
>
>
>
> --
> Thanks,
> Sarath.
>
> Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 |
www.quadone.com
>
>
>
>
>
>
>
>
>
> _________________________________________________________________
> View photos of singles in your area. Click Here
>
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fch\
annel%2Findex%2Easpx%3Ftrackingid%3D1046247&_t=773166080&_r=Hotmail_Endtext&_m=E\
XT
>

We elected 'b', and it worked fine. Sure, you don't get a "true" velocity, but
velocity itself is a means to an end, not the goal of using story points.

I found it better to use a rolling average (3 iterations) when calculating
velocity. In general, there was always stories that weren't quite finished, and
were credited in the next iteration. Also, using a rolling average helps smooth
out the hills and valleys, and IMHO, gives a more accurate measure of the speed
of the team.

Mark

--- In scrumdevelopment@yahoogroups.com, "steveteske" <steveteske@...> wrote:
>
> We are having a lively debate about Size Points.  I am calling the
"Conservation of Size Points Debate", because the following practices of your
SCRUM Masters:
>
> Either a) If you don't finish a backlog item, estimate the remaining size of
the backlog and assign it to the next sprint, giving partial credit to the
failing sprint (thus preserving the overall size points)
>
> or b) If you don't finish a backlog item, give yourself zero credit in the
failing sprint and carry over the size points (without reduction) to the next
sprint.  When you actual finish the backlog, you get count credit for in the
sprint in which it is finished...but it's full credit from the original size
points (don't reduce).
>
> Mathematically these two paradigms result in EXACTLY the same velocity
calculation.
>
> Here's my dilema:  I think the math above does not reflect true velocity.  I
don't have a palatable explanation of why partial credit schemes will fail to
delivery the correct velocity measurement.  But the harder isssue is the
politics of counting instantaneous velocity (counting only the things that are
DONE) and discarding the size points of partially completed work appears to
reduce the overall backlog size.  It appears that size points are disappearing
if I count only the "Done" work.  While I believe this promotes a better
understanding of TRUE velocity, the politics and the Math of what I call
non-conservation of size points is apparently either my misunderstanding of
SCRUM or it's a bridge too far for my director to sell to Project Management
because in non-conservation of size points, it looks like size points are
mysteriously disappearing.
>
> I don't have a problem with disappearing size points because according to my
math, if I have TRUE velocity and the total size points to the next release,
I've got what I need.
>
> I am not sure how to deal with conservation vs. non-conservation of size
points.
>
> Help would be appreciated.
>
> Steve Teske
> Thales Communications Inc., Clarksburg, MD
>

Hello,

We as a newbie scrum team are just finished our first pilot/simulation sprint.

Our team didn't care about the burn-down chart and I think it's because actual
burn-downs never decreased, each day new unexpected tasks (because of the legacy
software's dependencies) are popped up and so it's went up. I think this is
demotivated the team about the chart.

Is this normal? What do you suggest?

>
> I would say that this is a weak definition of the Scrum Master.
> Describing the role, in its entirety, relative to the Product Owner is
> a bad idea.
>

Agreed.  This is an excerpt, not the whole definition.  I was asking about this
part of the definition.  Do you see the ScrumMaster as being the conduit between
the team and the product owner?

Scrum for Managers by Mitch Lacey

Most of us have heard of Scrum and some of us have probably run some projects
with it. It calls for cross functional, self organizing teams that are
accountable to deliver working software every sprint. That's great if you're a
team member, but what if you are a manager or senior leader in you company?
Where do you fit in?

Mitch Lacey worked at Microsoft and helped onboard teams to Scrum and agile
principles and practices. Some successfully made the jump and some didn't. Come
listen to this talk and learn what Scrum is – its values, principles and core
framework and hear about the teams who successfully made the transition – and
how those managers roles were different than their counterparts on the teams who
didn't successfully transition.

Mitch Lacey is an agile practitioner and trainer. He has been managing projects
for over twelve years and has numerous plan-driven and agile projects under his
belt. As a Certified Scrum Trainer (CST) and a registered Project Management
Professional (PMP), he shares his experience in project and client management
through Certified ScrumMaster courses, Agile coaching engagements, conference
presentations, blogs and white papers. Mitch is also an SDSU Alum.

The meeting will be held at the Cardinal Health San Diego R&D HQ
(http://xpsd.org/CardinalHealthDirections) from 6-7:30 PM on Thursday April
2nd.  Also, XPSD continues to look for a new home, please contact Carlton
Nettleton (cnett@...) of June Clarke (joon@...) if you can
host our group each month.

>
> >
> > I would say that this is a weak definition of the Scrum Master.
> > Describing the role, in its entirety, relative to the Product Owner is
> > a bad idea.
> >
>
> Agreed.  This is an excerpt, not the whole definition.  I was asking about
this part of the
> definition.  Do you see the ScrumMaster as being the conduit between the team
and the
> product owner?
>
The Scrums that I have seen be the most successful are the Scrums that have the
Product Owner as part of the Team.  If we wanted to talk about conduits, I would
say the ScrumMaster is helping the stakeholders get information they normally
would not get.

Carlton

Hello, inanc_gumus.  On Wednesday, April 1, 2009, at 10:18:10 AM,
you wrote:

> We as a newbie scrum team are just finished our first pilot/simulation sprint.

> Our team didn't care about the burn-down chart and I think it's
> because actual burn-downs never decreased, each day new unexpected
> tasks (because of the legacy software's dependencies) are popped
> up and so it's went up. I think this is demotivated the team about the chart.

> Is this normal? What do you suggest?

What would the team need to learn to do better so that the chart
would be useful?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Attend our CSM Plus Course!
http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

I agree with you, Mark. I am not sure if the overhead of splitting
stories and then calculating the balance is worth the effort. Its easier
to communicate the progress for even those stories not done using words
than numbers.

Jayanthan

woynam wrote:
>
>
> We elected 'b', and it worked fine. Sure, you don't get a "true"
> velocity, but velocity itself is a means to an end, not the goal of
> using story points.
>
> I found it better to use a rolling average (3 iterations) when
> calculating velocity. In general, there was always stories that
> weren't quite finished, and were credited in the next iteration. Also,
> using a rolling average helps smooth out the hills and valleys, and
> IMHO, gives a more accurate measure of the speed of the team.
>
> Mark
>
> --- In scrumdevelopment@yahoogroups.com
> <mailto:scrumdevelopment%40yahoogroups.com>, "steveteske"
> <steveteske@...> wrote:
> >
> > We are having a lively debate about Size Points. I am calling the
> "Conservation of Size Points Debate", because the following practices
> of your SCRUM Masters:
> >
> > Either a) If you don't finish a backlog item, estimate the remaining
> size of the backlog and assign it to the next sprint, giving partial
> credit to the failing sprint (thus preserving the overall size points)
> >
> > or b) If you don't finish a backlog item, give yourself zero credit
> in the failing sprint and carry over the size points (without
> reduction) to the next sprint. When you actual finish the backlog, you
> get count credit for in the sprint in which it is finished...but it's
> full credit from the original size points (don't reduce).
> >
> > Mathematically these two paradigms result in EXACTLY the same
> velocity calculation.
> >
> > Here's my dilema: I think the math above does not reflect true
> velocity. I don't have a palatable explanation of why partial credit
> schemes will fail to delivery the correct velocity measurement. But
> the harder isssue is the politics of counting instantaneous velocity
> (counting only the things that are DONE) and discarding the size
> points of partially completed work appears to reduce the overall
> backlog size. It appears that size points are disappearing if I count
> only the "Done" work. While I believe this promotes a better
> understanding of TRUE velocity, the politics and the Math of what I
> call non-conservation of size points is apparently either my
> misunderstanding of SCRUM or it's a bridge too far for my director to
> sell to Project Management because in non-conservation of size points,
> it looks like size points are mysteriously disappearing.
> >
> > I don't have a problem with disappearing size points because
> according to my math, if I have TRUE velocity and the total size
> points to the next release, I've got what I need.
> >
> > I am not sure how to deal with conservation vs. non-conservation of
> size points.
> >
> > Help would be appreciated.
> >
> > Steve Teske
> > Thales Communications Inc., Clarksburg, MD
> >
>
>

> In many ways, the ScrumMaster's role in regard to the Product Owner
> can be seen as a kind of liaison for the team, reinforcing its
> communication with the Product Owner. As such, he or she is an
> essential hub for communication,

A single person acting as "hub of communication" for the team is
generally a bad idea for any agile project. Developers, Testers,
Product Owner, etc., should be talking directly to each other.  A
coach or scrum-master would help make sure this communication occurs
by facilitating some parts of the process, and reminding people to
have conversations when helpful or necessary. Interested stake-holders
should be attend demo meetings instead of just receiving progress
reports.

--
C. Keith Ray, IXP Coach, Industrial Logic, Inc.
http://industriallogic.com      866-540-8336 (toll free)
Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
http://agilesolutionspace.blogspot.com/

Sent via BlackBerry by AT&T

Reading this post gives the distinct impression that you perceive there are
rules to how Scrum works.  My understanding is that there are guidelines and
principles, not hard-n-fast rules.  I believe Scrum is not intended to be a
playbook with rules to run a scrum by, but rather a set of guidelines to be
considered as the scrum team figures out how to most effectively build the
software functionality the PO deems most desirable (and 'pays' for) for any
given sprint.

So, I'd first recommend that:

> "Is it possible, as a scrumteam, to plan in our own stories,
> even if the product owner disagrees?"

is a moot point for this forum.  The implicit answer is "Of course it's
possible" from a Scrum philosophy perspective.

But I suspect that's not the intent of the question.  You cannot get "advice"
from this group that will enable you to bypass your own internal politics.  It
seems to me you're looking for permission to do something your team deems
appropriate for more effective software creation but haven't gotten the
'go-ahead' to do it for whatever reason (including not having asked yet).

If your workday is governed solely by what backlog items exist in your sprint
backlog, then this is really a question for your PO.  Bottom line, you need to
convince the PO that taking the time (possibly incrementally over a few sprints)
to make adjustments to your team's development process can have positive
benefits for the PO's investment to "allow" it to happen.

Of course, there is the philosophy of self-organization in Scrum.  If your
organization supports self-organization deeply enough, I would suggest you need
not get permission - that the team decides what workday efforts are appropriate
to complete a sprint once the sprint backlog has been decided.  So, you could
simply have the team agree to fewer backlog items and roll the process
improvement into the development process (again, possibly incrementally) until
complete.  Your team velocity may take a hit, but then again, so does the speed
of a sailboat as you adjust your sails to take better advantage of atmospheric
conditions.

Bill Berger

Mike, what on earth are you talking about? I have no idea if you agree or
disagree with our comments.

Mark

--- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
>
> Then why do all this work and then cop out at the end.  Stay with conventional
practices folks. We need people with this kind of thinking to not consider
themselves part of this community.
> Agile and Scrum are about done.  AIG and other loser approaches about
rewarding whining and in doing so ripping off this country and this world.
> Yes it hard work and not much fun. Most of all you have to lose to be
successful. That is a lot better than what you are suggesting.
>
>
> Sent via BlackBerry by AT&T
>
> -----Original Message-----
> From: Jayanthan Bhattathiripad <jynthn@...>
>
> Date: Wed, 01 Apr 2009 12:36:00
> To: <scrumdevelopment@yahoogroups.com>
> Subject: Re: [scrumdevelopment] Re: Conservation of Size Points, AKA: Partial
>  Credit for Backlogs
>
>
> I agree with you, Mark. I am not sure if the overhead of splitting
> stories and then calculating the balance is worth the effort. Its easier
> to communicate the progress for even those stories not done using words
> than numbers.
>
> Jayanthan
>
> woynam wrote:
> >
> >
> > We elected 'b', and it worked fine. Sure, you don't get a "true"
> > velocity, but velocity itself is a means to an end, not the goal of
> > using story points.
> >
> > I found it better to use a rolling average (3 iterations) when
> > calculating velocity. In general, there was always stories that
> > weren't quite finished, and were credited in the next iteration. Also,
> > using a rolling average helps smooth out the hills and valleys, and
> > IMHO, gives a more accurate measure of the speed of the team.
> >
> > Mark
> >
> > --- In scrumdevelopment@yahoogroups.com
> > <mailto:scrumdevelopment%40yahoogroups.com>, "steveteske"
> > <steveteske@> wrote:
> > >
> > > We are having a lively debate about Size Points. I am calling the
> > "Conservation of Size Points Debate", because the following practices
> > of your SCRUM Masters:
> > >
> > > Either a) If you don't finish a backlog item, estimate the remaining
> > size of the backlog and assign it to the next sprint, giving partial
> > credit to the failing sprint (thus preserving the overall size points)
> > >
> > > or b) If you don't finish a backlog item, give yourself zero credit
> > in the failing sprint and carry over the size points (without
> > reduction) to the next sprint. When you actual finish the backlog, you
> > get count credit for in the sprint in which it is finished...but it's
> > full credit from the original size points (don't reduce).
> > >
> > > Mathematically these two paradigms result in EXACTLY the same
> > velocity calculation.
> > >
> > > Here's my dilema: I think the math above does not reflect true
> > velocity. I don't have a palatable explanation of why partial credit
> > schemes will fail to delivery the correct velocity measurement. But
> > the harder isssue is the politics of counting instantaneous velocity
> > (counting only the things that are DONE) and discarding the size
> > points of partially completed work appears to reduce the overall
> > backlog size. It appears that size points are disappearing if I count
> > only the "Done" work. While I believe this promotes a better
> > understanding of TRUE velocity, the politics and the Math of what I
> > call non-conservation of size points is apparently either my
> > misunderstanding of SCRUM or it's a bridge too far for my director to
> > sell to Project Management because in non-conservation of size points,
> > it looks like size points are mysteriously disappearing.
> > >
> > > I don't have a problem with disappearing size points because
> > according to my math, if I have TRUE velocity and the total size
> > points to the next release, I've got what I need.
> > >
> > > I am not sure how to deal with conservation vs. non-conservation of
> > size points.
> > >
> > > Help would be appreciated.
> > >
> > > Steve Teske
> > > Thales Communications Inc., Clarksburg, MD
> > >
> >
> >
>

On Tue, Mar 31, 2009 at 6:39 PM, steveteske <steveteske@...> wrote:
> We are having a lively debate about Size Points. I am calling the
> "Conservation of Size Points Debate", because the following practices of
> your SCRUM Masters:
>
> Either a) If you don't finish a backlog item, estimate the remaining size of
> the backlog and assign it to the next sprint, giving partial credit to the
> failing sprint (thus preserving the overall size points)
>
> or b) If you don't finish a backlog item, give yourself zero credit in the
> failing sprint and carry over the size points (without reduction) to the
> next sprint. When you actual finish the backlog, you get count credit for in
> the sprint in which it is finished...but it's full credit from the original
> size points (don't reduce).
>
> Mathematically these two paradigms result in EXACTLY the same velocity
> calculation.
>
> Here's my dilema: I think the math above does not reflect true velocity. I
> don't have a palatable explanation of why partial credit schemes will fail
> to delivery the correct velocity measurement.

Right. What some, including myself, have advocated is that you size up
the remaining work and give zero credit for work in the current
iteration that was not completed. In this way you somewhat
underestimate the actual effort that was expended, but you account for
the fact that some of that effort was wasted (in the sense that
whatever was produced was not deliverable at the end of the
iteration.)

This is not conservative of points. Points are arbitrary by
definition. So, not conserving them doesn't hurt me one bit.

This approach makes all kinds of sense to me. I am a musician. Also, I
practice martial arts. In both of those avocations we strive to
perform accurately and fast. In order to go fast we have to push
ourselves. There will always be a speed that is too fast for us to
perform accurately. So, we slow down to the point where we are
accurate again and gradually increase our speed.

What I am saying is that missing a story is like missing a note. The
correct response is to slow down and stop missing them. Then speed up
again.

  But the harder isssue is the
> politics of counting instantaneous velocity (counting only the things that
> are DONE) and discarding the size points of partially completed work appears
> to reduce the overall backlog size. It appears that size points are
> disappearing if I count only the "Done" work. While I believe this promotes
> a better understanding of TRUE velocity, the politics and the Math of what I
> call non-conservation of size points is apparently either my
> misunderstanding of SCRUM or it's a bridge too far for my director to sell
> to Project Management because in non-conservation of size points, it looks
> like size points are mysteriously disappearing.
>
> I don't have a problem with disappearing size points because according to my
> math, if I have TRUE velocity and the total size points to the next release,
> I've got what I need.
>
> I am not sure how to deal with conservation vs. non-conservation of size
> points.
>

I would tell them that the missing points represent waste. Effort was
expended that did not result in any story being delivered and that
effort does not count. The re-estimate of the story accounts for the
amount of effort it will take to recoup that loss. Since you aren't
going to redo anything you already did, the new cost is not as high.

I would also point out that story points are arbitrary and there is no
reason to believe that they are conservative. If that doesn't go over,
I would point out that effort is conservative in the same way that
energy is: we know that the sum of the energy in equals the sum of the
energy out. We also know that only a portion (Often a very small
portion) of that energy produces work. Our velocity in Scrum is a
measure of the work we produced in the iteration, not of the total
effort that went in.

In other words:

Total Effort = Effort that produced running tested software + Waste

Velocity = Effort that produced running tested software *during the iteration*

Hi Nicolas,

Do you think renaming objects in a model would take a significant amount of
time? It doesn't *sound* like a big deal, on the surface. If not, then just do
it as you work through other items.

Did the team know of the naming conventions required to go to prod? If so, then
why didn't they follow the required conventions the first time?

If the team didn't have that information, then why not? Could be a communication
breakdown in the organization, or a lack of collaboration with the architecture
team at the start of the project. These are not the PO's problem. Non-functional
requirements and organizational standards are the technical team's
responsibility.

You may not be able to demo this directly, but you can certainly explain the
situation to the PO. I'll bet he isn't stupid.

Cheers,
Dave

--- In scrumdevelopment@yahoogroups.com, Nicolas Mohamed <nicolasmohamed@...>
wrote:
>
> I don't know if it's ok or not, but it happens and that's the main point
>
> We (as a team) defined for this current sprint a task called "rename objects
> in the entity framework model". We did this because we have an architecture
> team which approves (or not) our code.
>
> If the code is not approved, it won't go to prod => PO will never see all
> the business value
>
> ¿Should we eliminate this task? ¿Should we do it silently consuming hours
> from other tasks? The PO does not even know it exists and we cannot show it
> in a demo because is not something visible.
>
>
> Nicolas
>
> ----------------------------------------------------
> www.unavisiondistinta.blogspot.com
>
>
>
> On Wed, Apr 1, 2009 at 2:36 PM, William Berger <Bill.Berger@...>wrote:
>
> >   Reading this post gives the distinct impression that you perceive there
> > are rules to how Scrum works. My understanding is that there are guidelines
> > and principles, not hard-n-fast rules. I believe Scrum is not intended to be
> > a playbook with rules to run a scrum by, but rather a set of guidelines to
> > be considered as the scrum team figures out how to most effectively build
> > the software functionality the PO deems most desirable (and 'pays' for) for
> > any given sprint.
> >
> > So, I'd first recommend that:
> >
> > > "Is it possible, as a scrumteam, to plan in our own stories,
> > > even if the product owner disagrees?"
> >
> > is a moot point for this forum. The implicit answer is "Of course it's
> > possible" from a Scrum philosophy perspective.
> >
> > But I suspect that's not the intent of the question. You cannot get
> > "advice" from this group that will enable you to bypass your own internal
> > politics. It seems to me you're looking for permission to do something your
> > team deems appropriate for more effective software creation but haven't
> > gotten the 'go-ahead' to do it for whatever reason (including not having
> > asked yet).
> >
> > If your workday is governed solely by what backlog items exist in your
> > sprint backlog, then this is really a question for your PO. Bottom line, you
> > need to convince the PO that taking the time (possibly incrementally over a
> > few sprints) to make adjustments to your team's development process can have
> > positive benefits for the PO's investment to "allow" it to happen.
> >
> > Of course, there is the philosophy of self-organization in Scrum. If your
> > organization supports self-organization deeply enough, I would suggest you
> > need not get permission - that the team decides what workday efforts are
> > appropriate to complete a sprint once the sprint backlog has been decided.
> > So, you could simply have the team agree to fewer backlog items and roll the
> > process improvement into the development process (again, possibly
> > incrementally) until complete. Your team velocity may take a hit, but then
> > again, so does the speed of a sailboat as you adjust your sails to take
> > better advantage of atmospheric conditions.
> >
> > Bill Berger
> >
> >
> >
>

--- In scrumdevelopment@yahoogroups.com, "William Berger" <Bill.Berger@...>
wrote:
>
[...]
> Bottom line, you need to convince the PO that taking the time (possibly
incrementally over a few sprints) to make adjustments to your team's development
process can have positive benefits for the PO's investment to "allow" it to
happen.

+1. It's the PO's decision, and if the team believe it's an real issue they can
provide information about the impact of the issue so the PO can make a
well-informed decision. He/she may not consider it as important an issue as the
team members do. Conversely, he/she might recognize the value of fixing it if
properly informed about the impact.

Cheers,
Dave