I think breaking down the tasks is a great idea!
Smaller Jira tasks go much better together with our hybrid Jira-sprint
model way of working.
The same goes for the web UI, for instance "Partial Implemenation of
User Interface (UI) for the first sprint (Web Interface)" -> I will
break that into smaller tasks later.
/Anne
On 17. feb.. 2009, at 08.53, Hirsch, Richard wrote:
I agree that Jira is probably best place to base the sprints. I
think the current tasks are too broad.
For example, ESME-6 ( https://issues.apache.org/jira/browse/
ESME-6 ) is "Support for Twitter API". Should we break this down
into smaller Jira tasks. If you look at the official wiki from
twitter (http://apiwiki.twitter.com/REST+API+Documentation), there
are already categories ("Status Methods", "User Methods", etc.).
That might be easier.
Ideas?
P.S. I also like the way the twitter wiki is structured to document
their REST API. Maybe we can use it as a basis for our documentation.
D.
-----Ursprüngliche Nachricht-----
Von: Vassil Dichev [mailto:[email protected]]
Gesendet: Dienstag, 17. Februar 2009 07:08
An: [email protected]
Betreff: Re: Next Sprint
I read that David isn't going to have a lot of time for this sprint.
What about Vassil and Darren?
As usual, I have a moderate amount of time in the hours after son goes
to sleep :)
Besides the obvious choice of work on the UI (where we are way
behind),
REST API and Twitter API, does anyone else have other suggestions.
Twitter API is what I'm going to concentrate on, my todo list there is
fairly big and I don't want to bite off more than I can chew. Besides,
most other tasks influence all of ESME (groups, permissions), so it's
necessary for more than one person to agree on how we want it
implemented.
To summarize my view on the topic of whether sprints are useful- like
Darren, I also think it's beneficial to set some short-term goals,
even if we're not 100% successful. One planning problem here is that
everyone is moving at a different pace every sprint. Prioritized lists
would be of real help here. JIRA could fit quite nicely in this case,
I think.
