The SCRUMPY tool looks like it could be perfect for what I am looking for. I too have become frustrated managing a backlog in excel. However, we use a different points system than the tool provides and as we are a fairly mature team in the scrum process I don't want to change now and have to work out the velocity variation.

Is it possible to change the points associated with the "T-Shirt" sizes?

I am happy to hack about some of the files if needed but thought I'd ask if there is a simple way to do it.

I see. I guess these would correspond to the following T-Shirt sizes: 1=XS, 2=S, 3=M, 5=L, 8=XL, 13=XXL ?

That sounds logical to me. It would be Ideal to have a XXXL=21 (or any other large number) which we use to define a story that is too large to estimate. Perhaps some sort of ? Unknown story point value??

Yes. I like your idea. I think it is better to make the uncertainty explicit rather than a using some arbitrarily large story size to indicate that we don’t know how big something is. A story with a size of zero points effectively becomes a prioritisable placeholder in the backlog but because it has no size it will have no impact on the Product Velocity calculations or the Forecast dates of the other stories. It is visible to us but effectively ignored. This seems logical and is of value I think.

I have added support for zero sized stories and made the Story size scheme accessible as a property in the scrumpy.properties file in the cfg directory as follows:

# The default Geometric Story Size Scheme
scrumpy.storySizes=XS=1,S=2,M=4,L=8,XL=16,XXXXL=128
# For a Fibonnaci Story Size Scheme use the following line instead:
# scrumpy.storySizes=XS=1,S=2,M=3,L=5,XL=8,XXL=13,XXXL=21

Note that if you change this property existing stories entered under the old scheme may not display their size correctly. Their size will be blank and you will have to edit each Story to be the size you want under the new scheme.

This shouldn't be a big problem as most people have one scheme and stick to it. Anyone changing this property should do so before entering their Stories. Going forward I will consider providing support for user definable Story Point Schemes from within the application. Hopefully this should be good enough to get you started.

I want to do a bit more testing but with a bit of luck I will ship it this evening.

In our team, there is a significant difference between zero point stories and question marks. Zero means a story that is so trivial that it is almost free. We try to keep our estimates in the Fibonnaci range as well, 1, 2, 3, 5, or 8 for anything we take into a sprint. Larger numbers are epics that we'd want to see broken up before bringing them into a sprint. But sometimes we have distinct "features" that are so small that they'd be maybe .25 in the numbering scheme above. We don't want to bump them all up to 1, because that would throw off our velocity numbers. So in practice, we accumulate the rounding. Maybe the first one gets 1 point, then the next couple get zeroes, then another 1, then a couple more zeroes, to try to even it out.

A question mark, on the other hand, is truly unknown. The way ScrumWorks handles these is it won't let you take an unestimated backlog item into a sprint, but you can have it on the backlog. Whatever charts show projected completion dates highlight any ranges that include unestimated stories, so you know not to rely on them. In database terms, a question mark is a null, not an integer zero.

My preference would be for question marks to be handled as nulls, but if they are going to be treated internally as an integer, then I would like for it to be configurable. Since I need zero to be a valid estimated size, I'd probably opt to translate questions marks to 999.

It turns out having even just a handful of "unestimated" items at 999 plays havoc with my product chart. I opted to add a new "size" called unestimated which is valued at -1. That gives me a way to have my own version of question marks and leaves zero for items that were actually estimated at zero points.

Very interesting. Previously I also took the view that if an item it didn't have a size then it shouldn't be on the backlog. I changed my mind because it is useful to be able to keep items in view even when (as is often the case) we don't know how big they are. Also I observed that people tended to reach for XXXXL to indicate that the story size was unknown which seemed even more problematic. Zero story points was chosen to mean "Unknown" for convenience as it didn't have any effect on the charts or velocity calculation. As I am sure you are aware -1 will also throw Scrumpy out albeit by much less.

I will give it some more thought eventually the underlying concepts will show themselves. In the meantime I have made the zero point label configurable in 1.4.0 so that you can assign whatever name you think best.

# The default Geometric Story Size Scheme
scrumpy.storySizes=?=0,XS=1,S=2,M=4,L=8,XL=16,XXXXL=128
# For a Fibonnaci Story Size Scheme use the following line instead:
# scrumpy.storySizes=XXXS=0,XS=1,S=2,M=3,L=5,XL=8,XXL=13,XXXL=21
# Or even like this if you prefer not to use the T-Shirt sizes:
# scrumpy.storySizes=0=0,1=1,2=2,3=3,5=5,8=8,13=13,21=21

Would it help if the story size was represented as a real number rather than as an integer? e.g.

Real numbers would give flexibility. I could use it in the short term to distinguish questions marks from true zeros. (I'd make the question mark .001 or something.) It would also accomodate the full range of points that are used in the "planning poker" cards that I've seen. They include a half point card which wouldn't fit in Scrumpy otherwise.

Awesome, thanks Adam for getting a new release out so quickly. Have downloaded and had another play and it now seems to do everything I wanted that excel cold not do.

Tomorrow I will have to start the rather onerous task of transferring my Backlog to this new tool to give it a proper workout - but I am going to take the opportunity to re-evaluate the priorities with the main stakeholder of my current project so hopefully it will be a productive exercise.

Tomorrow I will have to start the rather onerous task of transferring my Backlog…

Be aware that I have just released version 1.3.0 which has a few database schema changes (hence the minor version number increment). If you go ahead with version 1.2.3 you will have to migrate your Product Backlog data from 1.2.3 to 1.3.0 should you want to take advantage of the new features. This isn't too difficult for me because I have the knowledge of how the schema has changed. I suspect it could be a good deal more effort for you.

If you can I strongly recommend grabbing the new version from the download page.

The schema should be stable again for a while now and database migration is something I am going to be looking at next…