Re: Agile Estimation - User stories for non-user driven functionality?
- --- In email@example.com, "Casey Manus"
>What I do (and many others, too, I think) on projects like this is to
> * Do you create user stories for "infrastructure like" pre-
> requisites to developing the user facing functionality in our user
> stories? User stories for things like building new developer
> workstations, upgrading the database to SQL 2005, building base
> classes, etc all seem wrong, save maybe the SQL 2005 upgrade because
> you can tie that to an operation problem.
have a so-called "Iteration Zero" that is dedicated to building
workstations, getting the tools set up (database upgrade, etc.) and so
Regarding how to handle technical tasks going forward, there's not a
cookbook approach, but there has been a discussion of that very
subject on the Extreme Programming discussion group, here
http://tech.groups.yahoo.com/group/extremeprogramming/. You might be
able to cull some useful ideas from that thread.
>IMO that's normal at the outset of a project, and even moreso for a
> * The confidence level of our user story points seems to be low.
> We did an initial pass at them, and then we immediately starting
> second guessing them. The team didn't seem to all have the same idea
> of what "done" was going to mean for us and not everyone had been
> deeply involved in the spike (although everyone was supposed to be).
team of people who haven't worked together before. Iteration by
iteration the team's estimates should become more and more consistent.
You're right to think that the definition of "done" is important. The
team needs a consensus about that before estimates or velocity
measurements can become useful.
> * We have "completed" 3 sprints prior to starting this project,To me, the red flag here is that you're not reporting the truth. There
> and our reported velocity has been about 11 points, but in actuality
> our velocity was probably only around 5, because our defect rate has
> been high, we haven't been doing enough unit testing;code
> review;acceptance testing, basically we aren't living up to the
> definition of "done" we all agreed to.
shouldn't be a "reported velocity" for public consumption and a
different, semi-secret "actual velocity". Transparency is a key value
of agile development.