Re: Sorting out User Stories

> On 27 Feb 2015, at 04:28, Sandro Hawke <sandro@w3.org> wrote:
> 
> On February 26, 2015 6:45:48 PM EST, Harry Halpin <hhalpin@w3.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> 
>> 
>> On 02/26/2015 11:06 PM, Jessica Tallon wrote:
>>> I’m just thinking wouldn’t the +0 and -0 distinction in the voting 
>>> be lost if you just add them all up? Could you possibly count +0 
>>> and -0 as +0.2 and -0.2 respectively or some similar value which 
>>> takes into consideration the distinction between the two?
>>> 
>> Looking at the stories, it might make sense to count up which ones
>> have rough consensus (mostly all +1) and which ones have significant
>> objections (-1), and which ones are on the border (+/- 0s) and thus
>> keep all 3 totals in separate columns.
>> 
>> That might get lost in counting and merging, since some stories have
>> more votes than others, although the variation is minor.
>> 
> 
> Indeed, something with 5 +1's and no -1's is in good shape.  Something with 10 +1's and 4 -1's is in terrible shape.    Summing the survey results doesn't really work.
> 
> I think I'd try to put the stories into one of three buckets: Yes (consensus), Not-Much-Interest (very few +1's, maybe up to three), and Conflict (four or more +1's and one or more -1).
> 
> The actual cutoff for enough +1's to matter will depend on the data.   Hopefully there are few on the border.

I agree, one can classify the stories into these that have conensus and those that don't.
The issue then remains as to how to proceed. Should the controversial stories be put
aside? Or should they rather be the focus of attention? As Harry Halpin will confirm, 
Bernard Stiegler the philosopher of technology who run the research institute named IRI 
at the Pompidou center  (where Harry was employed for the past few years) and who had a 
keynote at WWW2012, lays controversy at the foundation of democratic thinking. It is 
by working  on the controversial aspects that one makes progress in understanding 
reality, where  research needs to be focused, and what needs to be investigated further. 

Following that principle one should then look at the reasons given against a position 
and see if the reasons really make sense, and what kind of sense they make. A number
of ways can be followed to reach consensus

1. amending the story

One type of -1 reason given was "out of scope: we do not do access control"

But we know that this group is not doing access control, yet we know a distributed social 
web needs it. So a user story cannot ignore access control. Fixing this -1 just requires 
adding at the top of the story: "This user story does not make the group liable to
build access control".

2. consistency

Another reason given sometimes is "the story is too complicated" . Yet there 
are stories  with 40 steps such as Tantek's 
https://www.w3.org/wiki/Socialwg/Social_API/User_stories#RSVPs_invitations_comments_to_an_event

So if that reason is to count as a reason one should then add the same -1 to that story too, 
or at least the difference between those stories has to be made clear.

3. empirical research

Some other type of -1 was "it is too complicated to build this"
But that is just an opinion that may be able to be proven to be false by empirical
research. One way of falsifying the claim can be "this story was implemented
in software X. Or a demo could quickly be built to show falsify the claim.

4. versioning

The group may be wise to argue that some stories should be deployed at 
a future version. But can a -1 based on a subjective idea of what version 
a story belongs be a decisive factor in evaluating the user story as a story?
Certainly not all features may be implemented now. 

But this leaves a lot of options open.

Some things may be done outside the group in the development of an 
ontology ( ie. vocabulary ), and so may be done immediatly by 
interested groups and not in a future version. The API should then be 
designed to allow them to do so. 

Other stories may be pushed to a later version, but then it still is 
important for the current API to make sure that future versions are possible.

5. Have I forgotten anything?

I certainly have.

But you get the gist. Scores need to be interpreted. And this is a process
that should help move the group to understand better the different
positions put forward. That itself can help understand what needs to be done.


Henry





>   - Sandro
> 
> 
>> 
>>> Thanks, Jessica.
>>> 
>>>> 26 feb 2015 kl. 22:46 skrev Evan Prodromou <evan@e14n.com>:
>>>> 
>>>> I'd like to suggest the following lightweight framework for 
>>>> sorting out our 90 (!) user stories for the social API.
>>>> 
>>>> I propose we divide them into 3 groups: Undisputed. All positive 
>>>> or 0, no negatives. Net positive. Summing up the +1's and 0's
>>>> and -1's gives a positive number. Net negative. Summing up the
>>>> +1's and 0's and -1's gives a negative number. All of these would
>>>> have a net sum of votes shown. It would give us a rough idea of
>>>> where we have consensus or near-consensus, and where we have
>>>> very little consensus.
>>>> 
>>>> I can spend some time this weekend working on it for next week's 
>>>> call.
>>>> 
>>>> -Evan
>>>> 
>>> 

Social Web Architect
http://bblfish.net/

Received on Friday, 27 February 2015 17:39:47 UTC