Agilo 1.3 Backlog Sorting

[janiv]

Hi,

I'd like to sort the back log by priority.
How do I do it?

Thanks,
Janiv Ratson.
http://blogs.microsoft.co.il/blogs/janiv

[Robert Buchholz]

Hey Janiv,

On Thursday 10 June 2010, janiv wrote:
> I'd like to sort the back log by priority.
> How do I do it?

Let me simply refer you to two recent threads that discussed the removal
of the default sorting:

http://groups.google.com/group/agilo/browse_thread/thread/a065ba1ddbb61935/c2ec217d6c68c175#c2ec217d6c68c175
http://groups.google.com/group/agilo/browse_thread/thread/ab57821f459bca55/20564afdc9402a0c

Hope this helps

Robert

[janiv]

Thanks,
Are you planning to add this feature soon?

Janiv.

On Jun 14, 10:55 am, Robert Buchholz <robert.buchh...@agile42.com>
wrote:

> Hey Janiv,
>
> On Thursday 10 June 2010, janiv wrote:
>
> > I'd like to sort the back log by priority.
> > How do I do it?
>
> Let me simply refer you to two recent threads that discussed the removal
> of the default sorting:
>

> http://groups.google.com/group/agilo/browse_thread/thread/a065ba1ddbb...http://groups.google.com/group/agilo/browse_thread/thread/ab57821f459...
>
> Hope this helps
>
> Robert

[Robert Buchholz]

Hey Janiv,

On Monday 14 June 2010, janiv wrote:
> Are you planning to add this feature soon?

I'm not sure I understand you correctly. The feature has been removed
during the backlog switch from form based to JavaScript/ajax. We're not
currently planning to re-add it.

Regards
Robert

[Chris Manning]

I have been following the various threads about the removal of backlog sorting, and I also feel that you should consider re-adding some ability to automatically sort the backlogs. As it stands the product backlog is much harder to use. Previously it was easy for the product owner to prioritise and reprioritise requirements by changing their business value. Now the business value is somewhat useless as they have to manually drag the requirements into the order they desire anyway. On a large backlog this is quite a hassle, especially for new requirements that are added at the bottom of the backlog. There may well be a better way of doing things, than the old way, that gels better the new backlog (as I do quite like the ability to manually sort tasks in the sprint backlog), but I do feel that something needs to done to get the best of both worlds, and make requirement prioritisation less manual.

Aside from this one change I very much like the changes that were made in 1.3. I especially like the new burndown chart.

Chris Manning

Integrated POS Solutions

[Martin Häcker]

Hi Chris and janiv,

Am 17.06.10 23:09, schrieb Chris Manning:

> I have been following the various threads about the removal of backlog
> sorting, and I also feel that you should consider re-adding some ability
> to automatically sort the backlogs. As it stands the product backlog is
> much harder to use. Previously it was easy for the product owner to
> prioritise and reprioritise requirements by changing their business
> value. Now the business value is somewhat useless as they have to
> manually drag the requirements into the order they desire anyway. On a
> large backlog this is quite a hassle, especially for new requirements
> that are added at the bottom of the backlog. There may well be a better
> way of doing things, than the old way, that gels better the new backlog
> (as I do quite like the ability to manually sort tasks in the sprint
> backlog), but I do feel that something needs to done to get the best of
> both worlds, and make requirement prioritisation less manual.

We are thinking about a way to achieve this without loosing the nice
manual sorting. We're hesitant to go for clicking on headers to sort by
that field as the interaction with drag'n'drop is complex. iTuens does
it, but it's not very intuitive when drag'n'drop works and when it doesnt.

Perhaps a "Sort stories by Business-Value button" is actually the right
aproach to ease this? (Feedback welcomed)

I do however feel that using the Business-Value for sorting is actually
abusing it, as the business-value shouldn't change if you want to
re-order stories so while it robs you of some functionality I think
that's actually a change for the better to reflect the real business
value in that field.

> Aside from this one change I very much like the changes that were made
> in 1.3. I especially like the new burndown chart.

Thanks! It's always nice to hear that!

Regards,
Martin

[Chris Manning]

On 21/06/2010, at 8:50 PM, Martin Häcker wrote:

We are thinking about a way to achieve this without loosing the nice
manual sorting. We're hesitant to go for clicking on headers to sort by
that field as the interaction with drag'n'drop is complex. iTuens does
it, but it's not very intuitive when drag'n'drop works and when it doesnt.

Perhaps a "Sort stories by Business-Value button" is actually the right
aproach to ease this? (Feedback welcomed)

I was thinking about it some more, and realised that this really only applies to requirements. The ability to manually sort stories within requirements, and tasks within stories, is really handy. So maybe an option to sort requirements by business value, as you suggest, would be all that is needed.

I do however feel that using the Business-Value for sorting is actually
abusing it, as the business-value shouldn't change if you want to
re-order stories so while it robs you of some functionality I think
that's actually a change for the better to reflect the real business
value in that field.

I hadn't really thought of it like this. I guess it largely depends on how people use the business value. The way we use it (largely because of how it worked prior to 1.3, and hence how we started using it), is that if a requirement becomes more or less important for a client/stakeholder then it has a greater or lesser business value for us (after all it is the clients that pay the bills :-)). I guess the case could be made though, as you say, that the business value and priority aren't directly related. I wonder then if it is actually the ROIF that is more important to prioritising. Logically it does make sense to do a requirement with business value 100 and total story points of 1 and hence roif of 100, before one with business value 2000 and total story points of 200 and hence roif of 10. 

The only problem with this in our case is that we have tended to be lazy by only adding stories and/or story points, for higher business value requirements, as we are not likely to get to the lower ones anytime soon, so it seems silly to plan them too much. We should probably add them all though, as now I see that not having them is reducing our ability to prioritise effectively.

So if the option could be extended to sort requirements by business value and/or roif then it would give people to flexibility to use it in slightly different ways depending on how they wish to do things.

As a developer myself (as no doubt most people using your product are :-)), I am well aware however that you can never please everyone, and that often what the users of a system think they want, isn't what they actually want, and that often there are better ways. The tricky thing is usually getting them to accept a change. As such I am open to other options, and will even adapt to the current method if necessary.

[Martin Häcker]

Hi Chris,

I really agree with most of what you say.

Am 21.06.10 23:49, schrieb Chris Manning:

> The only problem with this in our case is that we have tended to be lazy
> by only adding stories and/or story points, for higher business value
> requirements, as we are not likely to get to the lower ones anytime
> soon, so it seems silly to plan them too much. We should probably add
> them all though, as now I see that not having them is reducing our
> ability to prioritise effectively.

Well, I'd say to that that you really should not prioritize everything,
but still start with the most valuable stuff.

Your PO however should try to engage the team now and then to figure out
very rough complexity estimates for what he wants and then use the value
as well as the (first) complexity estimate for prioritization.

Then you will break the stuff with the highest ROIF down further and
improve the estimates by doing so.

> So if the option could be extended to sort requirements by business
> value and/or roif then it would give people to flexibility to use it in
> slightly different ways depending on how they wish to do things.

Yeah.. The problem with that is that having many options makes it really
hard to evolve the product. :/

> As a developer myself (as no doubt most people using your product are
> :-)), I am well aware however that you can never please everyone, and
> that often what the users of a system think they want, isn't what they
> actually want, and that often there are better ways. The tricky thing is
> usually getting them to accept a change. As such I am open to other
> options, and will even adapt to the current method if necessary.

Well, the current best practice is to reduce the number of items in the
backlog to a number that enables sorting by dragn'n'drop to not be
hurtfull anymore. The logic being that if you have too many items you
are generating waste and should instead focus it on being more detailed
in the top priority items.

Thats not the nicest of answers I gather - but the best practice we
would like to encourage right now.

Regards,
Martin

[Hartmut]

Hi Martin and others,

there seems to be more than one way of doing things within Agile/Scrum. We seem to use one of those... ;-)

For us

• the BL is the place to keep all stories for the product (i.e., it is very long)
  
• we evaluate stories with custom variables (business value, technical value, general risk) and use a bit of math to combine them into a story priority - no manual sorting involved, needed, or wanted
• we use milestones are used to structure stories over longer time periods (i.e. a story has a high business value, but PO decided the feature is for next year's release)

For us, sorting the backlog by story priority is a mandatory feature (preferably by any presented attribute). So far, we have been using customized reports with big sql statements to get the sorted backlog. But the report does not provide the very useful in-line/in-table editing of story properties.

Since a short while, we compute the priority automatically in the database via a trigger on ticket_custom and are now able to se the priority (and how its changing) directly in to BL view - change any of the evaluating values and the priority updates with it. Now it's just the automatic sorting that is missing.

For us, the drag-n-drop of stories looks very cool, but is of no practical use - but - as said earlier - use cases differ.

Another thing I would really love in the BL is to have a place to

• enter minimum, average, and maximum stories our team processes per sprint
  
• enter a number N of sprints into the future

and get the backlog with stories colored in green, yellow, and red for stories that will be, will most likely be, may be, and will certainly not be implemented within the next N sprints (sum of story points of ordered backlog is 0...N*min, N*min..N*average, N*average..N*max, >N*max). That's a great tool to show the PO what consequences forcing up a story has. In a spread sheet, this is very easy to do, but I hate the tedious and error-prone trac-export, excel-import, resort, trac-re-import steps.

For the mentioned difficult interaction between drag-and-drop (dnd) and sorting I would suggest to run the BL in eiher of two modes

1. manually sorted with dnd freely available (two-state button or checkbox indicating the feature)
2. automatically sorted by any attribute. Attempting dnd would keep the current sorting and switch back to manual. Because this would loosing the previous manual sorting, this operation could be protected by a query to the user

Regards,

    Hartmut