esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Kathrine Petteroe <>
Subject Re: AW: Next Sprint
Date Tue, 17 Feb 2009 08:01:25 GMT
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.


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  ( 
> 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 (, 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 []
> Gesendet: Dienstag, 17. Februar 2009 07:08
> An:
> 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.

View raw message