[Fiware-wpl] IMPORTANT Clarification

[Alex Glikson]

Option 2 sounds reasonable. This way we also don't need to represent 
individual sprints in that tracker - just releases (minor and major), and 
mapping of features to releases.

Regards,
Alex

P.S. BTW, do we need to keep the internal management of individual sprints 
and stories public?



From:   Juanjo Hierro <jhierro at tid.es>
To:     "fiware-wpl at lists.fi-ware.eu" <fiware-wpl at lists.fi-ware.eu>, 
"fiware-wpa at lists.fi-ware.eu" <fiware-wpa at lists.fi-ware.eu>
Date:   28/09/2011 04:03 PM
Subject:        [Fiware-wpl] IMPORTANT Clarification
Sent by:        fiware-wpl-bounces at lists.fi-ware.eu



Hi,

  I believe there is a point that we didn't clearly fixed during our 
meeting in Turin.

  It is about the relationship between trackers and Backlogs.

  The notion of Backlog is someway "abstract" from my point of view.   A 
backlog is just a set of related Themes/EPICs/Features/User-Stories. This 
means that we may well talk about the "Data/Context Management Chapter 
Backlog" as well as the "Publish/Subscribe Broker GE Backlog", being the 
second a subset of the first one.

  However, this doesn't mean that we have to use a separate tracker per 
each of the GE backlogs.   I would like to agree on a common, consistent 
approach to share across the different chapters.   I see several options:
1.      Have a single Chapter tracker where keep track of the whole set of 
Themes/EPICs/Features/User-Stories associated to all GEs in the Chapter. 
By defining advanced queries on fields related to name of the GE, as well 
as the kind of entry, users may get different views, depending on their 
needs. 
2.      Have a single Chapter tracker where keep track of the whole set of 
Themes/EPICs/Features associated to all GEs in the Chapter.   Then have a 
tracker per GEs dealing with User Stories for each and every GE in the 
chapter 
3.      Have multiple trackers, one per GE in the Chapter, each keeping 
track of the whole set of Themes/EPICs/Features/User-Stories associated to 
a given GE 
  In my honest opinion, I would go for option 2. because it would make it 
easier to keep a reasonable large (but not that big) backlog just for 
Themes/EPICs/Features while the more fine-grained work is handled 
separately (given partners responsible of a given GE enough independence 
in managing the Backlog for the GE they are implementing).    It may also 
make our life easier in front of reviewers and even UC projects who 
probably may just need to deal with entries at the level of granularity of 
EPICs/Features ...

  Any opinion ?   If I don't hear about any objection, I would go for 
option 2 :-)

  Best regards,

-- 
Juanjo Hierro
Chief Technologist on Software Technologies
Telefonica R&D Labs

email: jhierro at tid.es
phone: +34 91 48 32932
www.tid.es
twitter.com/JuanjoHierro

Oeste 1, Planta 5. Distrito C
Ronda de la Comunicacion s/n
Madrid 28050
Spain

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
Fiware-wpl mailing list
Fiware-wpl at lists.fi-ware.eu
http://lists.fi-ware.eu/listinfo/fiware-wpl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-wpl/attachments/20110929/aed2308d/attachment.html>