PFE: Unique story ranking

2 views
Skip to first unread message

Emiliano Heyns

unread,
Dec 22, 2008, 4:57:22 AM12/22/08
to Agilito development
In our projects, it makes sense to have stories have unique rankings;
stories with the same rank turn out to be either one large story, or,
when pushed, one actually is ore important than the other.

In the current Agilito version, ranks do not have to be unique, but
enforcing uniqueness shouldn't impact the current use of agilito;
where stories with the same rank are sorted "arbitrarily" within their
group, making them unique only sorts them non-arbitrarily. The only
change it would bring is that you can't (ab)use story ranking to
cluster stories into themes, but that might be better served by
explicitly introducing themes (/theme priority).

The patch implementing story rank uniqueness can be found on
http://projects.iris-advies.com/media/unique-rank.patch , and no, no
extras slipped in this time ;)

Christopher Johnson

unread,
Dec 25, 2008, 10:04:56 PM12/25/08
to agili...@googlegroups.com
One thing that comes to mind with feature...say you have a list in backlog of prioritized stories. You introduce a new story and want to put it somewhere in the middle of the existing ranking. You have to go and edit half the stories then before you are able to place it? Seems like a bit of a hassle if someone is accustomed to using sequential rankings when prioritizing the backlog.

We made need some kind of helpers to make reprioritizing easier if we are enforcing this. That is definitely an impact to existing users...I know the ajax drag-n-drop was part of the idea for that. Any other thoughts on how to make sure agilito isn't getting in the user's way?

Cheers,
Chris
--
Cofounder and CEO
ifPeople - Innovation for People
www.ifpeople.net
t: 678-608-3408 x16

Emiliano Heyns

unread,
Dec 25, 2008, 11:01:53 PM12/25/08
to Agilito development
On Dec 26, 4:04 am, "Christopher Johnson" <c...@ifpeople.net> wrote:
> One thing that comes to mind with feature...say you have a list in backlog
> of prioritized stories. You introduce a new story and want to put it
> somewhere in the middle of the existing ranking. You have to go and edit
> half the stories then before you are able to place it? Seems like a bit of a
> hassle if someone is accustomed to using sequential rankings when
> prioritizing the backlog.

That would be annoying ;) No, the patch automatically moves ranks
around so the desired spot falls free just before the new/updated
story is saved. The user doesn't need to do anything.

> We made need some kind of helpers to make reprioritizing easier if we are
> enforcing this. That is definitely an impact to existing users...I know the
> ajax drag-n-drop was part of the idea for that. Any other thoughts on how to
> make sure agilito isn't getting in the user's way?

I'm looking into drag-and-drop; the ajax part is actually not so hard,
but saving the results more so. I'm just getting up to speed with
Django, what I need is a way to submit just story ID + new rank to a
form or whatnot, and the patched save method would take care of
things, but ISTR that using GET for state modification is frowned upon
these days, and I haven't yet figured out how to do POST from ajax, or
what the receiving end should look like in Django.

Emile

Emiliano Heyns

unread,
Dec 27, 2008, 5:48:52 AM12/27/08
to Agilito development
On Dec 26, 5:01 am, Emiliano Heyns <Emiliano.He...@gmail.com> wrote:
> That would be annoying ;) No, the patch automatically moves ranks
> around so the desired spot falls free just before the new/updated
> story is saved. The user doesn't need to do anything.

Strictly speaking, the patch doesn't really enforce unique ranks, BTW.
There's no unique constraint on the database, and if you have 100
stories all ranked 1, this patch will not touch them. It's only when
you save a story that this patch does anything; it makes sure that no
other story has the rank the saving story has; everything with the
same rank or higher as the spry being saved simply gets its rank upped
by one. If the story being saved had a rank before, that gap is closed
during the save too (or ranks would soon grow out of control). Taking
to '100 stories with rank 1' as a baseline:

* save a new story with rank 5: you now have 100 stories with rank 1,
and one with rank 5
* save a new story with rank 4: you now have 100 stories with rank 1,
one with rank 4, and one with rank 5
* save story with rank 4, changing its rank to 5: you now have 100
stories with rank 1, one with rank 5, and one with rank 6
* save story with rank 6, changing its rank to 5: you now have 100
stories with rank 1, one with rank 5, and one with rank 6 (stories
with rank 5 and 6 have swapped ranks)
* save story with rank 1, changing its rank to 10: you now have 99
stories with rank 1, one with rank 5, one with rank 6, and one with
rank 10
* save story with rank 1, "changing" its rank 1: you now have 1 story
with rank 1, 98 stories with rank 2, one with rank 6, one with rank 7,
and one with rank 11

the patch doesn't compact the ranks, compacting is not something
easily achieved in bog-standard sql. Particular databases might have
stuff on board to help; MS SQL Server has CTEs which help you do this
with a single update statement, and PostgreSQL has something similar,
but all these are non-standard extenstions to SQL.

Emile

Emiliano Heyns

unread,
Jan 5, 2009, 7:21:11 AM1/5/09
to Agilito development
On Dec 27 2008, 11:48 am, Emiliano Heyns <Emiliano.He...@gmail.com>
wrote:
> On Dec 26, 5:01 am, Emiliano Heyns <Emiliano.He...@gmail.com> wrote:
>
> > That would be annoying ;) No, the patch automatically moves ranks
> > around so the desired spot falls free just before the new/updated
> > story is saved. The user doesn't need to do anything.
>
> Strictly speaking, the patch doesn't really enforce unique ranks, BTW.

Any thoughts on this? I acutely need all of these patches; they
currently live in my working area, but I want to check them in
somewhere for safekeeping. I could set up an alternate repository, but
cross-repository merging is not one of subversions' strong suits. I
generally prefer svn for simplicity, but maybe a DCVS (git, mercurial,
darcs) would be better for parallel development.

Thanks,
Emile

John Lenton

unread,
Jan 5, 2009, 8:23:23 AM1/5/09
to agili...@googlegroups.com
On Mon, Jan 5, 2009 at 10:21, Emiliano Heyns <Emilian...@gmail.com> wrote:
>
> Any thoughts on this? I acutely need all of these patches; they
> currently live in my working area, but I want to check them in
> somewhere for safekeeping. I could set up an alternate repository, but
> cross-repository merging is not one of subversions' strong suits. I
> generally prefer svn for simplicity, but maybe a DCVS (git, mercurial,
> darcs) would be better for parallel development.

I'll be checking this and the other patch later in the week. Sorry for
the delay.

--
John Lenton (jle...@gmail.com) -- Random fortune:
The trouble with a lot of self-made men is that they worship their creator.

Emiliano Heyns

unread,
Jan 5, 2009, 9:10:24 AM1/5/09
to Agilito development
On Jan 5, 2:23 pm, "John Lenton" <jlen...@gmail.com> wrote:
> I'll be checking this and the other patch later in the week. Sorry for
> the delay.

Thanks. The 2nd patch includes the unique-rank patch, which is small,
but still. Just so you know.

Emile

Emiliano Heyns

unread,
Jan 7, 2009, 6:58:21 AM1/7/09
to Agilito development
Latest patch file at http://projects.iris-advies.com/media/unique_rank-task_cards-excel_status-story_burndown.patch

This patch currently implements:
* Unique story rank upon save
* Printable task/story cards
* Iteration status export to excel
* Printable burndown chart
* Story burndown added to task burndown

I'm patching faster than you guys can review ;)

Next up: the task log screen.

Emile
Reply all
Reply to author
Forward
0 new messages