How about custom point values
I'd love to be able to set different scales based on the project type. So one project might have 1-10 scale, while another would have 0-2. This would allow me to make Tracker best fit my existing processes.
Official
Response
Promoted
Responses
-
Dear Pivotal, could we have an update on this!
This is a blocker for us. We could live without completely custom values, but to not offer values compatible with our Planning Poker decks (0, .5, 1, 2, 3, 5, 8, 13, 20, 40, 100) will make the move to Pivotal impossible. And that makes me sad, I so do want to move to Pivotal. -
Just to harp in on ideas here:
- I'd love to see 'longer' scales for values too. The 4 option sets are rather limiting
- I'd love to see multiple estimation levels too. With my situation in Product Management, we use the points to manage estimation for dev-time, and are jamming the 'product improvement/importance' into the comments. For example, there are some things that we want to do that take 4points of dev time, but only improve the product by 1 point; and vice versa. It would be nice to be able to track both - letting the dev team and management teams better prioritize the build cycles. -
I appreciate that tracker prescribes much of the process, eliminating choices that are meaningless or problematic... so I don't feel that more point choices will make us any more productive or our estimates any better...
A couple points, though:
- zero pt stories are allowed. I wrote a separate report requesting the ability not turn this off.
- It _would_ be useful support larger pt values (13/20/40 etc.) for "epics". We've had to find out some way around this. We've used a couple techniques (unsuccessfully):
(a) don't estimate these stories until we can break them up
(b) our highest pt value is "illegal" and denotes a story that needs to be re-estimated. These are both "hacks" around the tool
It would be nice to do this the right way. -
EMPLOYEE
3We have this feature in the Tracker backlog. Look for it early next year!
-
You may have seen that you can choose an exponential point scale that gives you 1,2,4,8 point stories.
-
-
-
Hey Dan, how about that one? it has been over a year. Just let us know if you guys are planning to implement that feature or not.
Thanks! -
-
Ummm... ...well?
-
-
-
-
-
This is not quite the same, and I know it's a complicated ask, but I would love to be able to adjust the point scale for an existing project. Our project currently uses 0-2 points, but we've come to the conclusion that we need a broader range than that. I'd be happy if we could change to the Fibonacci or exponential scale. This could be a simple mapping from the current to the new point system (0 = 1, 1 = 3, 2 = 8).
-
-
EMPLOYEE
2Just to make sure everyone knows, Tracker gives you the option of choosing from one of three different scales for your project:
Linear (1/2/3)
Powers of 2 (1/2/4/8)
Fibonacci (1/2/3/5/8)
As Dan says, we're also working on totally custom point scales.-
Any update on this? The last employee post in from a year ago.
-
-
Yes, I reallly need this, and I am waiting too. It would be REALLY good if we could have this, even in a paid version, it's ok too! =)
-
-
-
-
-
The choices are cool, but be careful. At some point at the beginning (starting the first story?) your choice of point scales is locked forevermore.
-
you could easily fix this by exporting your stories to CSV, find/replace point values, and drop it all back in...
-
-
-
-
-
I appreciate that tracker prescribes much of the process, eliminating choices that are meaningless or problematic... so I don't feel that more point choices will make us any more productive or our estimates any better...
A couple points, though:
- zero pt stories are allowed. I wrote a separate report requesting the ability not turn this off.
- It _would_ be useful support larger pt values (13/20/40 etc.) for "epics". We've had to find out some way around this. We've used a couple techniques (unsuccessfully):
(a) don't estimate these stories until we can break them up
(b) our highest pt value is "illegal" and denotes a story that needs to be re-estimated. These are both "hacks" around the tool
It would be nice to do this the right way.-
+1 for epics.
Someone suggested an idea that I liked: an epic is a story with arbitrary size (pt value) that can't be started.
This would be great for high level planning but prevent you from cheating the system by skipping detailed estimating. -
-
we would need the 13/20/40 estimates as well. We are using 8 as an blocker this is an ugly hack. So it would be perfect to have a support for epics!
-
-
-
-
-
In fact, we'd probably like to be able to have two levels of estimation. Yup, I know, but bear with me.
Before we get into nitty gritty detail on stories we t-shirt size everything (S,M,L,XL), and then assign broad costs to those t-shirt sizes.
An iteration or two before we start a story we'll detail cost it (drill into more functional and then ultimately technical detail).
It's useful having the t-shirt cost because that costing is done en-masse as a relative complexity costing, and so that provides the team with a means of re-adjusting overall project estimates as stories are accepted.
The detail costing exercise is really just a means of getting the team talking about detail in a group so everyone knows what's coming, though those in charge of planning like to think that the detail cost is more accurate that the t-shirt (it sometimes is), and therefore have both available. -
-
Why does the fibonacci scale end at 8 btw? Is it a big issue to pin up a couple of more? Up to 21 for example, or is it not adviced within Agile Development?
-
-
Just to harp in on ideas here:
- I'd love to see 'longer' scales for values too. The 4 option sets are rather limiting
- I'd love to see multiple estimation levels too. With my situation in Product Management, we use the points to manage estimation for dev-time, and are jamming the 'product improvement/importance' into the comments. For example, there are some things that we want to do that take 4points of dev time, but only improve the product by 1 point; and vice versa. It would be nice to be able to track both - letting the dev team and management teams better prioritize the build cycles.-
So you're saying you want to track business value as well as effort/size for a story. That seems like a good idea for some teams. I've always found it hard to come up with a good scale other than high, medium, low...
-
-
-
-
-
How do we set points via a text box, not a pre-defined drop-down scale?
If this doesn't exist yet, can you add this as a feature request?-
I almost added this suggestion myself, but stopped because I actually like the "enforcement" aspect of only allowing certain values. Part of the problem is the appropriate values are context sensitive. For example, I'd like to enforce that a stories estimate has to be 5 or lower before it's scheduled for the current iteration, but larger estimates are good for epics which are kind of place holders in the backlog and for release planning.
-
-
-
-
-
My team also need more, larger point values; say fibonacci up to 21 or 34. Are there any plans for such a feature?
-
-
Is there a status on this. The note above says to look for it earlier next year? Well, we are almost a mid next year :)
-
-
I quite often use 13 (Fibonacci) to estimate larger or riskier stories, and I don't use 0 at all. I could just shift everything down a position (I didn't even realise you could have zero point stories), but I think 13 is useful. 21 would probably be too big, and need breaking up.
-
-
Just to be clear, I don't want to see custom point values (unless it enforces they are valid on the scale being used) but extending the scales to more than four/five values. At least 13 for Fibonacci. If people use varying scale limits in the wild, then maybe custom with validation is better.
-
-
I think this is probably a better idea than custom scales. I would not need custom scales if the existing scales were extended. In fact, that would seem like a good interim solution.
-
-
I’m
having to shift left everything on my point scale to make it work on a scale that only goes up to eight!
1Exactly. The idea is not to have epic stories, but 13 is still a reasonable point score for a large or risky story. If I were to give a story 21, I would break it up into a 13 and an 8 point story, or declare it as epic at 21 and not tackle it until it can be broken up. But having the limit set to 8 is just too low. If you look at Agile Estimating and Planning by Mike Cohn, you'll find 13 is used often for large stories. This simple limitation is pretty much a showstopper for me. Every other developer I know using Scrum uses a scale at least to 13. -
-
I’m
unhappy to use a whiteboard for the planning of big features only because I am missing 3(!) values on the scale
1the numbers above 13 would be great for the long range planning. When we are accessing new "things" we split them up in the main parts and use story points for each. We do not want to split the main parts it is enough to have a 13 + 20 + 40 to know the cost for the feature. Right now we need to track this on a whiteboard and use pivotal only for the tasks that are split up below 8 (so that we can use 8 as the blocker). -
-
So it has been over a year. Where is this feature in the backlog now? Would like a fibonacci sequence with 13,20 to throw in larger stories that won't be tackled for a while, and will be broken down as we get closer to implementation.
-
I'm waiting too!
-
-
-
-
-
Hi,
I'm also very interested in this feature.When could we have custom point scales available? -
-
We've been using .5 a lot in our preliminary pointing of stories.
The interface for entering points could be as simple as a text field. -
-
a) Any progress?
b) Smaller values are good too. Sometimes things are easy, and sometimes points end up just meaning too large. In these cases, 1/2, 1/4, and even 1/8 are totally useful.
c) At the very least, add 2 or 3 more levels to each of the three scales. -
-
-
-
Hi,
The perfect points value scale for me has been...
0.1
0.25
0.5
1
3
Now that may look strange but it's actually a great points value that represents time very well. Because teh above scale is in days...
So essentially 0.1 is very small 0.25 is 2 hours 0.5 is 4 hours and so on.
There is no 0 because nothing takes 0 amount of time ;)
I've used this points scale on multiple projects with multiple teams and it has always worked fantastically for new members coming into the team and just as well with seasoned members.
When you add the custom feature is there any chance you could allow it to use float values up to 2 decimals.
That would be great!
Justin :) -
-
Ah....
Thor Muller shared this idea over 3 years ago.
It ain't NEVER gonna happen then!!! LOL -
-
Look, I don't think you use the point scale correctly (0 is not supposed to be assigned to anything). You don't think I use it correctly (because I use a hybrid linear/power scale 1 1.5 2 3 4 6 8). Perhaps neither one of us is completely right. Or maybe there is no right or wrong on this.
At least tell us that custom point scales would complicate the UI too much, or that the program can't wrap its brain around certain custom scales.
Answering people's requests and concerns by telling them how you're right makes you come across as arrogant.-
It's never gonna happen! :) That's my take anyways
-
-
-
-
-
This would help very much, especially extension to the upper limit.
-
-
When will Custom Storypoints feature become available? There is a big discussion on this already for 1 year now. Can you inform me on the status?
This reply was created from a merged topic originally titled
Custom StoryPoints. -
-
Please let us choose additional story point values.
We use 1,2,3,5,8, 13, and 20. We would also like to be able to have 40 and 100. The visual display of story size doesn't seem very useful either, which is probably the reason for the limitation.
This reply was created from a merged topic originally titled
Why limit story point values? Give more flexibility here.. -
-
Need larger (13,20) values to do rough estimation of larger chunks
-
-
I completely agree with many commenters here. I'd like to use Pivotal for more than just a sprint kanban tool. Here is my workflow:
1. Talk with people/ideate and get rough feel for project, beers and napkins are often involved.
2. Take aspirin and pile of napkins to rough in a backlog of chunky stories that may take more than one iteration to do.
3. Use the chunky stories list for further discussion with folks from #1 to vet the viability of starting
4. I like the term "t-shirt size" the chunky stories. I like to use story points as in PT but these are obviously swags and much bigger than we would ever do in an iteration. Imagine a backlog of 20-200 point items. At least we have the ambiguity contained.
4. Decompose most obvious starting points and form a "backlog pyramid" where the most immediate stories are granular and well understood - and smaller typical ones. Defer the rest to later - if ever.
5. iteration to iteration continue to bust up the chunks as the team progresses down the backlog - or add new ones as required. My job as product owner is much easier because I'm always working from the same list and my "estimate" of project duration is always more or less up to date.
The way I do this now is to not estimate them in PT untill they are decomposed but it blows because I can't see my full project plan's estimate. I feel like I have blinders on so I end up making spreadsheets out of PT to do extrapolations. that makes me sad.-
You wrote "4. Decompose most obvious starting points and form a "backlog pyramid" where the most immediate stories are granular and well understood - and smaller typical ones. Defer the rest to later - if ever.
5. iteration to iteration continue to bust up the chunks as the team progresses down the backlog - or add new ones as required. "
Exactly. -
-
You also wrote "The way I do this now is to not estimate them in PT untill they are decomposed but it blows because I can't see my full project plan's estimate"
But that's the catch. *Can* you even provide good estimates for the stuff you haven't "busted up"? This is where selling the agile approach as a service works over selling a project spec - but I understand, the business world wants total costs up-front. How many software development projects come in on time under budget again though? :) -
-
-
-
-
this keeps coming up, and it feels like we can experiment with our process since we are constrained by such a low-resolution point scale.
-
-
This suggestion was over 3 years ago, and it was stated that it would be coming "early next year". 3 years later...no word, what's going on??
-
Maybe that estimate was based on a previous velocity that was a little off because they needed custom point values.
-
-
@pixelperfect - Oh snap!
-
-
-
-
-
My smiley below says it all..
-
-
How much would it cost to get this implemented? Let's do a community fundraiser and take care of this finally.
-
-
-
-
-
-
-
-
Hmm, if cookies won't make us implement custom point scales, not sure what will...:)
Seriously, apologies for the false hope when we first promised this. Too much on the plate, and we're always juggling priorities.
The good news is that we will be starting to tackle some core features in the next few weeks, and custom point scales are at the top of list.- view 2 more comments
-
-
-
Funny how after all this time all it took was the mention of cookies to get someone to notice the thread... Hmm I think I'll mention cookies on a few other PT threads that need attention ;)
-
-
it was the mention of fundraising, but then we smelled the cookies...
-
-
-
-
- view 1 more comment
-
-
Or cookies? :-)
-
-
Ok, when I say floats... you know I don't mean Coke floats... right? ;)
-
-
-
-
There is no reason why points should be limited to any maximum, except that it doesn't go well with the graphic interface.
Custom point values should be added, or point values could be set to arbitrary values (ie. from 0 to potentially infinite). That way very different tasks can co-exist (ones that take a few hours and ones that take several days)
This reply was created from a merged topic originally titled
Custom / freely set point values. -
-
Any status update for this feature request? I'd like to use this for a client to port the product backlog from Excel to PT. However, I therefor need to be able to use larger story points estimates (13, 20, 40, 100).
-
-
Hey guys, sorry, but we haven't been able to get to this yet. It's on the short list, but other things keep getting in front of it. Also, we thought we could squeeze it in, but it turned out to be harder to come up with a clean, easy to use solution for this that worked well with the existing interface (which is a common challenge for new features in Tracker).
We do plan to still tackle custom point scales as soon as we get some spare bandwidth. The good news is that we've grown the Tracker dedicated team, and you should start seeing results from that soon.-
I subscribe to the fibonacci sequence values and would like to have all the values commonly on estimation poker cards i.e. 0,1,2,3,5,8,13,20,40,100.
I also subscribe to the view that anything larger than 8 points is typically too large to bite off in a sprint, so I'd be fine with the little weight icon area displaying an "epic" icon if the points are larger than 8. This will act as a reminder to split the backlog item at some point, but still allow for some more complete release forecasting.
I do find it a little limiting not being able to measure anything above an 8, which is especially common at the start of a project.
Just a thought.
-Mike -
-
I subscribe to the fibonacci sequence values and would like to have all the values commonly on estimation poker cards i.e. 0,1,2,3,5,8,13,20,40,100.
I also subscribe to the view that anything larger than 8 points is typically too large to bite off in a sprint, so I'd be fine with the little weight icon area displaying an "epic" icon if the points are larger than 8. This will act as a reminder to split the backlog item at some point, but still allow for some more complete release forecasting.
I do find it a little limiting not being able to measure anything above an 8, which is especially common at the start of a project.
Just a thought.
-Mike -
-
-
-
-
We plan all our stories using planning poker and it is not uncommon to have a 20 point story given the nature of what we develop.
In order to be able to use this tool, I must have the following point structure: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, (40, 100), where 40,100 are nice to have but not must haves... -
-
Would definitely consider using PivotalTracker for our Pilot Scrum project if only their were higher values on the Fibonacci sequence (up to 100) so that we can manage ALL of the backlog items in one place.
Hopefully this feature will be implemented in the near future as it is probably stopping a number of teams from coming fully on board ;) -
-
I really would like to see a point scale like Derek proposed. But I think 40 and 100 is not nice to have. It is a must have for dealing roughly with bigger stories. Although PT is best project planning tool I've ever used, this is really a cut in our planning work.
Perhaps it could be possible then to set a limit to the maximum points of a story when it is planned in for the next sprint. Because I think it makes absolutely sence to have no stories in a sprint that have more than 8 points (Fibonacci).
I am looking forward to the next updates. Thanks for your great job! -
-
please please please! After 3 years, maybe some other things should be falling off the priority besides this!
-
-
3 years????? OMG! Please bring this one to the top of your backlog! 146 guys are waiting for this one.
-
-
We are currently evaluating PT, and although we would love to use it in our Scrum project there are two major issues for us:
1. the missing support of the full Fibonacci scale
2. the missing support for a self hosted system for smaller companies -
-
I've been using PT in various projects and this is always a problem. So I'll just add my voice to the choir and say: Custom points would be a very valuable addition.
-
-
A variation on custom points would be to override a story with your own estimate. So for instance we default to Fibonacci, but for the times we want to override that, we can enter our own estimate. Would love to see an update to this topic from the Pivotal team.
-
-
Could we initially just have the fibonacci series? No need for the complex stuff yet that is delaying this. The point visual is totally unnecessary and can be replaced with a simple number. I think you will gain many more clients if you do that.
We are still currently evaluating this. -
-
lol .. custom point scales are a good idea I'm sure ... but if you just added a couple of new options you would answer 90% of the complaints I'm sure (or even just extended the existing scales)
-
-
We are just usings pivotaltracker within our project. Because the project has just started, we have a lot of backlog items with points > 8
It would be very helpful if de fibonacci scale would be extended (13, 20, 40, 100), just like our cards.
This would make our life a lot easier. -
-
Adding 0.25 and 0.5 to the fibonacci scale would be great!
-
-
This arbitrary cap on 8 points is definitely a showstopper for me as well, it creates so much unnecessary overhead. And the full Fibonacci series should be much simpler to implement than most other planned stories, such as integration with bug trackers.
-
-
I was hoping to use the point scale as the estimated days to complete each animated shot on a tv show production. however without having a custom field to enter (or for my cases, 0-10 points) would be enough. but maxing out at 4 won't work for our situation unfortunately, unless you start having to do math in your head as you read the values which i would like to avoid if it all possible.
Please bring us more point options! -
-
We have used following point scale before:
0.5, 1, 2, 3, 5, 8, 13, 20, 40
(our poker planning cards contains this scale)
The problem is now especially the missing of 0.5 and 13 point estimates. It is not possible to change our scale on existing projects.
This reply was created from a merged topic originally titled
Fibonacci point scale should contain 0.5 and 13 point estimates. -
-
I like this idea. I was about to ask for it; however, I'd like to see an additional option. Include additional option that allows the user to enter an "other" value. For example, 1,2,3,4,5,6,7,8,other. If other selected allow the user to enter a number, e.g., 22. I know this is not the agile way. This capability would be nice as we use PT for tracking projects that aren't development in nature. We use it to track other business projects where actual hours would be nice to track. Getting these folks to understand story points is nearly impossible.
-
-
I have a problem with applying the story points sequence (fibonacci) - it happens very often that beside the implemented sequence 0,1,2,3,5,8 also 13 & 20 occure. Is it possible to add this two numbers? This would be very helpful!
This reply was created from a merged topic originally titled
Implemented part of Fibonacci - Sequence is hard to use!. -
-
Can i change the story points options? we use 1,2,3,5 and 8 to estimate effort. Looks like currently you use only 1, 2, 3.
This reply was created from a merged topic originally titled
change/add story points value?. -
-
i like the idea of them being custom. my main need, however, is having support for epic range (8, 13, 20, 40, 100...)
-
-
Just checked out Pivotal Tracker. I'm really surprized you limit story point estimates to 1,2 or 3. This really isn't sufficient for points estimating. We use Fibbonacci numbers, usually from 2-13. Anything bigger is probably too big.
This reply was created from a merged topic originally titled
Need More Than 3 Story Points. -
-
Our team won't use the software before custom point ranges are supported. We simply cant match out already created stories down in PivotalTracker.
-
-
Dear Pivotal, could we have an update on this!
This is a blocker for us. We could live without completely custom values, but to not offer values compatible with our Planning Poker decks (0, .5, 1, 2, 3, 5, 8, 13, 20, 40, 100) will make the move to Pivotal impossible. And that makes me sad, I so do want to move to Pivotal.-
Completely agree. We HAVE TO HAVE the epic range (13, 20, 40, 100) to use this tool. A 100 might need to be broken up, but it still needs to be trackable until it is and we have had 13 and 20 point stories in iterations. Sure we try to avoid it, but it happens and if the tool can't take the value then it can't get our velocity right.
-
-
-
-
-
I completely agree with this. It's been three years since this ticket was filed. We're PT premium customers, but are finding that the absence of custom points a huge pain. We aren't able to adapt it to our pricing model, and might have to move away from PT if this isn't resolved.
Can somebody at PT give me a rough indication of when we can get custom points ranges? -
-
I agree again... and again. I don't know about other people, but I find I need these extra points to denote epics in the product backlog 'iceberg'. It's perfectly normal to start with a huge story and break it into smaller stories over time, as you move closer to starting development on it.
I'm just reiterating what everyone else has already said to see if more comments = more action. -
-
The biggest weakness of Pivotal is the point system. You can't on one hand have the very limited options you have, then on the other leave the value of a point vaguely defined as "a relative, team-specific measure of effort to complete a feature story. It can be based on something concrete, like ideal engineering days, but over time it becomes an intuitive, relative metric" (from the FAQ). That's BS. The limited options in fact prescribe a very specific value to points, yet you don't come out and say what that value is.
The point system my team uses, which has been refined over a couple years, is an exponential scale where 4 points = ~ 1 day of work. Therefore 1 pt is equal to something how to make the point system actually fit a real-world development process. -
-
We're trialling Pivotal right now and would like to move over completely, but the restrictions on points is the one thing that gets in the way. There's no way we can abandon all our previous estimates/velocity values to fit with Pivotal and we need to be able to give a rough (large) estimate on epics.
I want to ask Pivotal when this is happening, but it seems even if I did get an answer I would have a hard time accepting it as for three years people have been waiting for this without much joy. -
-
Can we get an update on whether an extended scale is still on the radar? The release burndown graph is unusable until we can have 13 and 20 in our backlog
-
-
When will have the ability to have stories larger than 8 points. We like to keep the whole backlog optomised with stories in the distant future often being less will defined and larger. As stories get closer to the current sprint they are refined and broken down if possible to make them 8 points or less. Though with our team of 9 we would really like to be able to have 13 point stories in the sprint
This reply was created from a merged topic originally titled
We need stories larger than 8 points. -
-
This is critical if you'd like to be considered for 99designs (0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100). We use Mountain Goat Software card decks. It's fine to be opinionated but please not on this. Your solution looks great by the way. My monthly Jira hosted subscription is up for grabs... ?
-
-
I want to add to this.. This seems to be such a small enhancement:
just add a bunch of value to the Fibonacci scale: 1, 2, 3, 5, 8, 13, 20, 40, 100
If you do this, there is no retroactive calculation, mapping or anything, customers will readjust there stories if they need to manually. I don't see the big deal here.
I can understand that having a totally customizable point scale can be tougher than it looks but adding 4 values to the Suite seems a total no brainer.. And looking at the length of this thread you guys should set the priority pretty high for this right?
I see a lot of people saying it's a blocker, they can't fully migrate, etc.. that would help you get more customers!! -
-
-
YEaaahhhh!!!!!!
-
-
-
-
-
That's nice and all, but the request included fractional points. Our planning poker cards include the 1/2 point, which with our interpretation of the value of a point is extremely useful to have. It would be a little overkill to try to double all our estimates in order to obviate the need for a half point.
-
Hi Victor,
Fractional point values will require an API version change (floating point vs. integer), but we do plan to add 0.5 as a supported point value soon. Look for it as part of the APV V4 release. -
-
-
-
-
-
-
Thanks gang, this was tops o' the list for us. The planning poker decks are out and about.
-
-
I'd love to see a story point sequence like Mike Cohn proposes. ?, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity.
This reply was created from a merged topic originally titled
Another story point sequence?. -
Loading Profile...



Twitter,
Facebook, or email.
EMPLOYEE



















