Story point estimations - Discovery

Stephen Niedzielski

26 Jan 26 Jan

8:02 p.m.

\o/ This is awesome! At my last gig, we started using "t shirt" size columns (small, medium, large, XL) when we had a couple epics worth of stories to point. It was much easier to keep a sense of scale when sizing stories next to each other. Each story card would land in a size column and there would often be some column adjustments in the process, "how could that possibly be a 'medium' when this is an 'XL'???" On the Android team, I know we generally point new event logging functionality at two points but otherwise the definition is still a bit murky for me. Glad to see this kind of definition! Stephen On Tue, Jan 26, 2016 at 12:51 PM, Kevin Smith <ksmith(a)wikimedia.org> wrote:

...

I just added a section to the Discovery process page[1] documenting the guidelines that the Portal team uses for story point estimation. I would like to include a corresponding section for the Analysis team. It can be entirely different, since story point values never cross team boundaries. [1] https://www.mediawiki.org/wiki/Wikimedia_Discovery/Process#Story_Points Kevin Smith Agile Coach, Wikimedia Foundation _______________________________________________ discovery mailing list discovery(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Reply

Deborah Tankersley

8:44 p.m.

Thanks, Kevin - this is exactly what I was looking for! Cheers, Deb -- Deb Tankersley Product Manager, Discovery Wikimedia Foundation On Tue, Jan 26, 2016 at 1:17 PM, Kevin Smith <ksmith(a)wikimedia.org> wrote:

...

I have always shied away from T-shirt sizing, because I want to be able to compare relative sizes mathematically. How many "small" stories could we do instead of a single "large". Fortunately for me, nobody on the team pushed for T-shirt sizing, and we agreed on this number system as a group. Credit to Julien for proposing the basics, which the team tweaked to produce the posted result. Phabricator does allow string entries in the points field, by the way. I just don't like them. :) I look forward to the next several weeks, when we should start to be able to measure velocity and refine the estimations. Kevin Smith Agile Coach, Wikimedia Foundation On Tue, Jan 26, 2016 at 12:02 PM, Stephen Niedzielski < sniedzielski(a)wikimedia.org> wrote:

\o/ This is awesome! At my last gig, we started using "t shirt" size columns (small, medium, large, XL) when we had a couple epics worth of stories to point. It was much easier to keep a sense of scale when sizing stories next to each other. Each story card would land in a size column and there would often be some column adjustments in the process, "how could that possibly be a 'medium' when this is an 'XL'???" On the Android team, I know we generally point new event logging functionality at two points but otherwise the definition is still a bit murky for me. Glad to see this kind of definition! Stephen On Tue, Jan 26, 2016 at 12:51 PM, Kevin Smith <ksmith(a)wikimedia.org> wrote:

I just added a section to the Discovery process page[1] documenting the guidelines that the Portal team uses for story point estimation. I would like to include a corresponding section for the Analysis team. It can be entirely different, since story point values never cross team boundaries. [1] https://www.mediawiki.org/wiki/Wikimedia_Discovery/Process#Story_Points Kevin Smith Agile Coach, Wikimedia Foundation _______________________________________________ discovery mailing list discovery(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

_______________________________________________ discovery mailing list discovery(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Reply

Guillaume Lederrey

7:44 a.m.

I need to take time to read the full page, lot of interesting information. And since it is sharing time... On one of my previous team, we used a purely relative sizing. During estimation, we sorted tasks from the simplest one to the most complex, without attributing any numeric size (or t-shirt or whatever). Once we had everything sorted, we looked for jump in complexity. For example, the first few tasks seem to have roughly the same complexity, and suddenly the next task in the list is clearly much more complex. At this point, we have groups of tasks of similar complexity. The first group is a complexity of 1, the second of 2, and so on, following Fibbonacci. This worked really well for us. Remarks: * as human, we tend to be fairly bad at absolute measurement, but we tend to be fairly good at relative measurement ("this is heavier than that" vs "this is 4 kg and that is 3.5 kg") * when doing group estimation, absolute estimation tend (for us at least) to generate much.more discussion and disagreement * this system might seem to be easily biased by the kind of tasks we have in our backlog, but in practice, it is fairly stable I hope this give idea to someone else... On 27 Jan 2016 08:24, "Stas Malyshev" <smalyshev(a)wikimedia.org> wrote:

...

Hi!

I just added a section to the Discovery process page[1] documenting the guidelines that the Portal team uses for story point estimation. I would like to include a corresponding section for the Analysis team. It can be entirely different, since story point values never cross team boundaries. [1]

https://www.mediawiki.org/wiki/Wikimedia_Discovery/Process#Story_Points Thanks! This is very helpful. On my $job-1, we used the same Fibonacci scale, with assumption that 8-point task is roughly a week, and then down from it. Tasks that are bigger than 8 were frowned upon - which usually means converting to epic or something like that, for epic pretty it's ok to have a lot of points derived from subtasks. -- Stas Malyshev smalyshev(a)wikimedia.org _______________________________________________ discovery mailing list discovery(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

Reply