You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I'm looking for a recommendation and/or advice on how to best utilize the original story points field.
The out-of-the-box scrum template obviously has the story points field. If I associate the original story points field with the same story screen, I'm concerned that users will be confused as to what field to complete. In essence, they would see a "Story Point" field followed by the "Original Story Point" field.
I'm looking for some recommendations/insight into how those in the user community utilize the "Original Story Point" field.
Do users simply use the "Original Story Points" field within Advanced Roadmaps for Jira app and not expose the field within the screens?
Thank you in advance for your recommendations.
Hi @Robert Campbell ,
Sorry for the slow response to this question.... I was a little confused by this at first but I've done some investigation and I think it looks like "Original Story Points" is just an Advanced Roadmaps field that is only applicable for use in the Live Plans interface.
It is described on this page: https://www.atlassian.com/blog/jira-software/ew-features-portfolio-for-jira-2-2
There is a new column you can add labeled “Original Story Points” or “Original Estimates” (depending on your estimation unit) in the scope section of your plan where you can input your initial estimates. This will give you a rough estimate of the amount of work that is needed to get your projects delivered. You’ll always have this column to refer to as you break down and provide more detailed story estimates. This allows you to compare the accuracy of original estimates with current ones.
However, this field is not accessible directly on Jira issue screens and can only be accessed in Advanced Roadmaps and only in the old interface.
As we've now announced the deprecation of that interface I would recommend that you don't invest any time in making use of it.
Having said that, I would like to understand further your use cases for a feature like this? Or whether you were just investigating the capabilities of the interface?
Good morning Dave, my apologies for the late reply. I can't say I have a use case in mind. Advanced Roadmaps documentation mentioned a handful of fields, e.g. "Team", "Target Start", "Target End", and "Original Story Points". I've associated all of the fields with specific screens to facilitate the flow of information; however, I held off on adding the original story points field because I wasn't quite sure if it truly added value or if it would simply cause confusion. That's the reason behind the post.
Hi Dave and Robert, Can I use Orginal Story Points for keeping there estmates on start of the developing issue? In this time Orginal SP equals SP. Then when issue drop down to next sprint you can change just SP (SP will goes to commitment and velocity metrics) to the time when SP will go down to 0 and issue is finished ?
As I see in our company I have got access to this field but probably someone add it, because it's a custom field. I can use it in Advanced Roadmaps and directly on Jira issue screen.
@Dave I have a use case! We'd love to be agile (we aren't completely) so we are being asked to do roadmap planning at the quarterly level. To hold the line against just "planning whatever and hoping for the best" we ask our Technical Team to take a swing at Epic level Story Points for their Team and then we draw a line where their typical velocity for a quarter tends to net out (I try to pull it in actually ;) ). We'd like to see how "off" we are when we do our estimates at the Epic level - it's really a learning exercise for our Technical Team. We've tried to do it based on Time but (and they are correct) we suffer from a lot of interruptions so there is always the standard "well this and this happened". We've tried to remedy that too... working on it. Where we get caught up is I think they are significantly underestimating at the Epic level and I'd like to start pointing that out to them. I can also use this cold, hard math to have discussions with PO's and upper management.