Estimation and reporting in Jira scrum projects [Atlassian University Live webinar]

[Ben Thoma]

As part of an ongoing series, Atlassian University offered this free webinar to strengthen your Atlassian product skills and learn directly from Atlassian experts. In this webinar, we learned about how estimation and scope change impacts reporting in Jira Scrum boards.

Together we:

• Considered best practices for successful estimation

• Discovered how scope changes affect reporting

• Dived deep into the relevant board settings

• Answered your questions, live!

Speaking of those questions...

Yesterday's top 3 burning questions—and Atlassian's answers

@Ree Kent made sure you got the answers you needed most!

• Can scrum teams estimate bugs using story points?

  Atlassian Answer: The decision to add points to non-story issue types such as bugs, tasks and spikes can be controversial. Much of the decision is dependent on what points are used to measure. For example, some teams may use points to measure value delivered. In that case, it would be a best practice to only add points to stories. However, if the need is to measure how much effort the team commits to in any given sprint, then using points on other issue types could be acceptable.

  What points represent is something the team, and perhaps the organization, should agree on. Jira Software will allow users to estimate any standard issue type with points and those estimations are reflected on the agile reports.

• What is the advantage of estimating in story points instead of time?

  Atlassian Answer: Typically story points are used to measure effort, value and/or risk. The benefit of measuring stories using points is that teams can control how much complex work they include in a sprint and how much change they introduce at the end of a sprint, instead of focusing on how long a solution will take to deliver.

  Using Story Points, versus hours, reduces anxiety around accuracy. Sprint estimation becomes more and more reliable with practice. You can use actual hours, but it's not reasonable to assume that all hours of a week are productive. Dates don’t account for the non-project related work that inevitably creeps into our days: emails, meetings, and interviews that a team member may be involved in.  Dates have an emotional attachment to them. Relative estimation removes the emotional attachment. Developers have a general sense of how much they can accomplish during a 2-week sprint - allowing for over or underestimating. As a best practice, don't assign time values to story points.  Doing this obviates the main reason to use story points in the first place.

  This Atlassian article provides a deeper dive on this topic.

• What is the purpose of using both stories and sub-tasks?

  A story represents the product owner’s request. This is something that the entire scrum team may work on. Sub-tasks are the smaller pieces of work being assigned to individual team members to deliver a solution for the story.

  Using sub-tasks enables the team members to have their own work items for tracking progress. If there is a need to view planned workload, time estimation can be added to sub-tasks to then show all of the assigned issues and estimated time for each user. Time tracking may be needed for reporting and Jira Software supports this approach by allowing the Story Points field to be added to stories, and the Time Tracking fields to be added to sub-tasks.

  Keep in mind that adding, removing, estimating, and logging work on sub-tasks will only be reflected on reports if you have the Time Tracking setting set to Remaining Estimate and Time Spent.

What questions do you have for @Ree Kent and @Joanna Thurmann?

Watch the recording and ask them in the comments below!

This webinar is intended for scrum teams, power users and project administrators, and those preparing for a Jira certification exam. Topics will be relevant to Jira Cloud, Data Center, and Server.

[G subramanyam]

This is an excellent webinar and my chapter alone has many unique and huge RSVP's (62 RSVP'd) Screenshot inline:

Super fast yet excellent walk through by "Joanna Thurmann" and 70 QnA's have been answered in a span of 10-15 mins!

[Rob Horan]

Are there best practices or other resources around coming up with the best estimates?  This webinar was really helpful on how to use estimates once we have them, but 99% of the effort (as pertains to reporting) is coming up with realistic estimates, which is why I believe many do not use these features to the fullest.

[Ree Kent]

Rob Horan , here is an article from Atlassian that you may find useful. Story points and estimation  

Scrum Alliance has this article. Story Points Explained: The What, Why, and How 

However, the latter assumes you are using a scrum framework that aligns with Scrum Alliance. 

As for best practices, first the scrum team should decide what the estimates measure - capacity, complexity, risk ...etc. and focus on consistently measuring that item. This is where having relative estimates is very useful, especially when using points. For example, if the team can all agree a specific story is a 3, that can be used as a benchmark for comparison to other stories.

Then, revisit the estimates' veracity during the sprint retrospective and attempt to get better with each sprint. Remember that the purpose of this exercise is not to focus on mistakes, but to help the team learn and improve. 

I hope this helps!
Marie Kent 

[Rob Horan]

Hi @Ree Kent I appreciate that.  However those documents rely on story points, which may work for some, but definitely not for others, my teams included.  It also assumes everyone is following Scrum, which may not be true for everyone. 

Before asking why I would watch a webinar like this without being Scrum, let me just say I was hoping for help on how to come up with estimates, as my question suggests :)

Here's the thing about those articles: they work really well in a perfect world in which everything is structured perfectly and there's perfect order and harmony and everyone is an SME with over 4,000 years of experience.

In reality, I feel like so many people are asked to estimate tasks they have no understanding of, and therefore have no ability to estimate. This results in the person entering some arbitrary and overly optimistic value that has no basis in reality, doing so only because they were asked to provide an estimate.

So my question is really more along the lines of - how does one create an estimate when they just don't know what it will take to get the work done?

[Gyeorye Lee]

I missed this webinar. Are you going to shared the recorded video?

[Jaime Netzer]

It's linked now, @Gyeorye Lee — we're glad you're here!

[Jeff L Chamberlain]

Is there a way to access all the Q&A, there was some good questions and responses I'd like to go through now that I don't have to focus on the training at the same time.

[Allysha Bilges]

Agree!! The questions and their responses would be great or even a place to continue to answer and dialogue. It was to difficult for me to listen to the presentation and read/comment on all the great responses!! 

[Rob Horan]

I did a quick copy & paste, and I think I got everything in the Q&A.  The chat unfortunately... I didn't get to copy that.

[Jeff L Chamberlain]

Is there a way to get a copy of this? Much obliged.

[Ree Kent]

Jeff L Chamberlain, we tried to answer the most popular questions at the top of this blog. Was there a different specific question you had?

Thanks,
Marie Kent

[Jeff L Chamberlain]

There were a ton of questions in the log. I can't say specifically which ones, but I know I saw some interesting ones. It would be nice to see all of them, not just the top three or four. 

[Rob Horan]

I would be happy to send a copy of what I got to whoever would like it.  Its too bad there isn't an Atlassian Community Slack.  Then again I can only imagine the string of notification woodpecker sounds. 

Madness, thy sound is the Slack notification.

[Jeff L Chamberlain]

I'd definitely like it. Do you need an email or what is the best way? 

[Dorrit Riemenschneider-Denecke]

Should stories taken over to the next sprint be re-estimated?

Background:

• Assume that the team estimates with story points. If stories are worked on in one Sprint but not closed (for whatever reason) and therefore move to the next Sprint, should they be estimated again (because perhaps most of the work is already done)?
• Goal: to be able to realistically estimate how much the team can accomplish for the next sprint by comparing the total Story Points and Velocity.

Contra arguments:

• Scrum does not provide for re-estimating
• re-estimating corrupts the velocity

Alternative approach:

• split tickets towards the end of the sprint if possible and split storypoints
• however, there should still be a tested, shipable increment then

[Susan Payne]

I attended this webinar. We have a repository of training sessions on our internal sites. 

1. Is it allowed that I post this recording and Q&A on our internal site for Jira Align? 

2. Do those who didn't register and attend this course have access to the recording & Q&A?

[Jaime Netzer]

Hi @Susan Payne of course! You are more than welcome to share the recording linked above internally. That link is public, so it should work whether or not you initially registered. We'd be much obliged if you could include the link back to the source, so folks can come our way for more learning!