RE: The purpose of Story Points and estimating

+ 13 on this.

With a new team, it’s important to use every opportunity to reinforce the “we not I” part of agile. Decomposition and estimating is a good way to practice this in a simple and safe environment.

Eric
From: [email protected] [mailto:[email protected]]
Sent: Tuesday, December 01, 2015 6:35 AM
To: [email protected]
Subject: Re: [SCRUMDEVELOPMENT] The purpose of Story Points and estimating


One of the largest benefits of the estimation process is not the estimation itself, but the "conversation" part of the 3 C's (http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fronjeffries.com%2fxprog%2farticles%2fexpcardconversationconfirmation%2f&data=01%7c01%7cEric.Gunnerson%40microsoft.com%7cd9758bbac06b43d98af308d2fa5cc91f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2W4zWiOIb3Gugrfji%2fd3G1LmRu%2fOFpTvgEtSByo3fL8%3d>).  Yes, you can have these conversations without estimation, but for some developers, it's hard to have deep, meaningful conversations about the work until you decompose it well, and it's hard for them to decompose it well without some context of how long it's going to take to accomplish the work (even if the "estimation" is only "do you think that can get done in a day - i.e. story counting).

I think what you will find is that, the work that the team thinks they can get done in 2 sprints before they "estimate" the stories is much more than they realize they can accomplish after the estimation discussions.  In fact, I would bet that once you have deep conversations about the work, you will realize you are going to need 3 or 4 sprints to get everything done right because of all the things that you didn't think of at first glance at the scope of the work.

On Mon, Nov 30, 2015 at 8:24 PM, [email protected]<mailto:[email protected]> [SCRUMDEVELOPMENT] <[email protected]<mailto:[email protected]>> wrote:


In my scenario, we have a new scrum team.  They will be working on project "z".  They consist of 3 team members, a PO and a ScrumMaster.



They were interrupted during their sprint 0 activity for project z, and tasked with project x.  fantastic, we estimated it so the team can get an understanding of the work.  Somehow amazingly the new team is retasked with project y.



Project X is dead, may be revisited some future date, but project y is so important, they brought in another fulltime developer to support project y.



The dilemma here is the new built out dev team agrees this will take about 2 sprints, and once that is complete the team will be reorganized and we will start working on project z.



Given the change in priority (nevermind Weinberg escalating context switching costs or Usman's team stability) what is the purpose of estimating the stories.  The Dev team is committing to completing the work in two sprints.  The future team AND future work is quite different. Where does estimating this temporary project have value.  I do not think there is value in planning, since the work was split, and committed.  (the team obviously rough sized it already to be able to commit to a level within a sprint).  There is no value in establishing velocity as the team will change, so it is an anomaly that will have to be noted.



The only value I see is getting the team used to doing the work.  Am I missing something?