RE: ScrumMaster only one trying to do Scrum

Conservation of Size Points, AKA: Partial Credit for Backlogs

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 poi
 nts, 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

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: Conservation of Size Points, AKA: Partial Credit for Backlogs

Hello, steveteske.  On Tuesday, March 31, 2009, at 9:39:19 PM, you
wrote:

> I am not sure how to deal with conservation vs. non-conservation of size points.

What would happen if you didn't use size points at all?

Serious question.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Attend our CSM Plus Course!
http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
You don't need to see my identification.
These aren't the ideas you're looking for. Move along.

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Is it possible as a scrumteam to plan in our own stories in the sprint?

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?  

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

RE: Is it possible as a scrumteam to plan in our own stories in the sprint?

Re: Is it possible as a scrumteam to plan in our own stories in the sprint?

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

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: Conservation of Size Points, AKA: Partial Credit for Backlogs

ScrumMaster's role

Re: ScrumMaster only one trying to do Scrum

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.

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: Tester in Scrum Team: how do you involve testers into estimation?

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 <at> yahoogroups.com, Roy Morien <roymorien <at> ...> 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 <at> yahoogroups.com
> From: kcsarath <at> ...
> 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 <at> ...> 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%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1046247&_t=773166080&_r=Hotmail_Endtext&_m=EXT
>

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/