Mario, K-T
I understand the logic, and it does make sense from the EV
and PMCS perspective. What I am saying is that
a) a lot of things we are doing can be seen as either
"new feature" or "improvement". As an example, say
we have a working version of qserv that supports
a join expressed like this:
"select whatever from A, B where A.id=B.id."
Later, we add support for a better join:
"select whatever from A join B using (id)"
It feels more like an improvement to what we
already have working, right? But I don't think we
want to do this work under the overhead umbrella.
So, I just want the team to be sensitive to that
b) we are just starting the construction, and theoretically,
we should be starting writing from scratch, right?
We shouldn't be starting with discovering bugs, we
should first implement things, earn story points, and
then we can talk about bugs (in the code we already
earned points for)
I am also saying that when doing the estimates I didn't
really considered bugs as overheads. I guess I will need
to change my perspective when doing future estimates...
Jacek
On 09/11/2014 04:55 PM, Mario Juric wrote:
> On 9/11/14 16:05 , Kian-Tat Lim wrote:
>> Jacek,
>>
>>> So I am tempted to say that we only use "stories" (and epic),
>>> and forget "bugs" and "improvements", because these activities
>>> won't be captured in PMCS (or if they will be, it will be
>>> in some twisted way :)
>>
>> No, the point is that making bugs into stories will devalue all
>> of your story points, since the total is the same. I'm with Mario that
>> you *don't* want bugs and improvements in PMCS; they're part of overhead.
>>
>
> The theory is that bugs add no new value -- you've already claimed full
> credit story-point for the feature where the bug is, and the bug
> indicates that you shouldn't have (in EVM sense, opening a bug should
> really add _negative_ value; as you get it closer to being fixed, it you
> climb back up to zero; as a practical approximation, we say that the
> value of a bug is zero).
>
> Improvements are just a bug in how we set up our JIRA projects and
> should be removed as an issue type.
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1
|