[SCRUMDEVELOPMENT] The purpose of Story Points and estimating

[[e-mail] [SCRUMDEVELOPMENT]]

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?

[Wouter Lagerweij [e-mail] [SCRUMDEVELOPMENT]]

Hi Ed,

I think you already gave your own answer.

There's a lot of value in this team communicating about the work to be
done, and to continue doing that over the next sprints. If an estimation
game is the only way you can see to stimulate that communication then you
should keep on doing that. If not...

Wouter

Post by ***@hotmail.com [SCRUMDEVELOPMENT]
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?

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

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/).
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.

Post by ***@hotmail.com [SCRUMDEVELOPMENT]
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?

[Eric Gunnerson [e-mail] [SCRUMDEVELOPMENT]]

+ 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: ***@yahoogroups.com [mailto:***@yahoogroups.com]
Sent: Tuesday, December 01, 2015 6:35 AM
To: ***@yahoogroups.com
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, ***@hotmail.com<mailto:***@hotmail.com> [SCRUMDEVELOPMENT] <***@yahoogroups.com<mailto:***@yahoogroups.com>> 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?