When best to start estimating stories in story points?

[Iakiv Kramarenko]

From here: https://confluence.atlassian.com/display/AGILE/Estimating+an+Issue
I got that:

* Once estimated you should not change estimate, even if you get more details about the story.
* It completely ok to be inaccurate while your inaccuracy is the same from sprint to sprint.

From somewhere else and from my own experience I know that Story should match "Definition of Ready" in order to be taken into the sprint...

Since inaccuracy is OK then "Definition of Ready to be estimated" can be weaker than "Definition of Ready to be taken into sprint", can't it?

Do I miss something?

How "Defnition of Ready to be estimated" may look for the story?

Again... Taking into account that "inaccuracy is OK" then story can really lack any details, be just "several non-technical" sentences about what "the user wants from the system", don't it?
Then you will really save the time for the team, and still have good prediction by calculated velocity. The only thing you should follow is provide your almost "gut feeling" relative estimates at the same time of story life cycle - somewhere in the very beginning, when there is no any task breakdown, not too much details.

Once you have you first rough estimates, you can control "Definition of Ready to be taken into sprint" by pulling from PO details until you can finish breaking down story into sub-tasks.

And here is one more question, Will burndown charts work for "tracking" progress if you don't put any estimates in hours to them?

If yes it will be really awesome. Then I would really love scrum, because it will be so simple, not taking away time from developers via all this day-long meetings, and still provide managers with both prediction and "tracking of progress"...

Does it make any sense?

[pschaff01]

Hi Iakiv,

Great topic! Let's first talk about the JIRA Agile plugin and then about the methodology itself.

The JIRA Agile plugin will not recommend that you modify the estimation of an issue after the sprint has already started. This will be seen as a scope change by JIRA Agile and so this modification will not be shown in any JIRA Agile report. So for example, if you estimate one issue with 2 story points, start a sprint and then change this value to 3 story points, all the reports will still count the issue as 2 story points. This can be confusing for your users since they will know they worked 3 story points, but everyone who looks at the reports will think the team worked on only 2 for that issue. This will create an incorrect value for your team velocity and all the other reports. Since one of the most important ideas of the Scrum methodology is to learn about your team's velocity to improve it in each sprint, this scope change goes completely against it. On the other hand, since we know that scope changes may occur eventually, JIRA Agile will allow you to change the estimation of issues or add/remove issues from the sprint after it has started, but do remember that these modifications won't be shown in the reports at all.

The Scrum methodology will never allow you to perform a scope change based on the fact that this will create incorrect values on your team's velocity.

So, in my point view only, the best way to work is:

Create a measure to define (through story points), when the issue should be a subtask, story or an Epic. So for example:

< 5 story points = Subtask

=> 5 story points = Story

=> 10 story points = Epic

Once you have a system like this one defined, you will automatically have a pattern to define the types of the issues. After you have this defined, consider the priority of your tasks. What is critical? What is minor? What my customer needs me to deliver first? So once your issues are correctly prioritized, you will have two valuable information to start a sprint: How complex/long it is to deliver the issues and when should I deliver them. The highest priority should always be delivered first, while the minor implementations can wait a little longer to be delivered in future sprints. The only thing remaining now to define your sprint scope is: "How many story points can my team do per day/week/?". This question can only be answered by knowing your team and analysing the velocity reports after each sprint is done, so usually this is the most difficult criteria to define. If you can, start with low values for your sprint and analyse what is being done. For example:

My first sprint contains 20 story points and must be finished in two weeks working 5/7. I'll have to deliver 2 story points per day. I have 4 developers in my team, so each one of them must deliver 0.5 story points per day.

When this sprint is finished, analyse if all your developers were able to deliver these story points per day and if the value set for the sprint was too high or too low. After analysing the reports after each sprint you'll have a good definition of story points per sprint.

I know we may have gone a little bit further on the response but I believe this will help you with the "Definition of Ready to be taken into sprint" question. The issue will be ready to be estimated once you analyse its complexity and have a clear understanding with all your team on "how complex is one story point" (will it take 1 hour? 1 day? 1 week?). Once the issue is estimated, define the sprint scope by limiting a story point value per sprint (doing this by analysing the progress of velocity charts from previous sprints) and measure this value with the priority of the issue. Once this is done, the issue is ready to be taken into sprint.

Regarding to the second question ( Will burndown charts work for "tracking" progress if you don't put any estimates in hours to them?):

The charts (including burndown) will show the value you are using for estimation in your board. If it's "time spent", then the graphs will be filled only with time values. If the estimation of the board is set to "Story points", the graphs will only be filled with story points. The "Estimation" configuration is set in the "Estimation" tab of the board's configuration.

Hope this helps!

Cheers,

Pietro Schaff