[Fiware-wpa] [Fiware-wpl] IMPORTANT Clarification

[Alex Glikson]

I'm a bit concerned that the fine-grained details of individual stories 
and tasks might potentially reveal internal details of our background 
assets -- some of which are not supposed to get exposed to the public.
Also, it might be just too many details for anyone outside the development 
team. So, I think we should look for a reasonable level of details in the 
public tracker of each Chapter (and the corresponding Wiki space). It 
seems to me that the level of minor releases (3 months long) and features 
associated with each of them (as well as the prioritized backlog of 
unassigned features, grouped by Themes) is just about right granularity.

Regarding using Forge tasks for management of user stories and sprints -- 
in addition to the privacy issue above (e.g., we might want to keep them 
in Forge spaces of individual WPs), I'm not sure it is customizable 
enough. For example, I haven't found a way to define a custom field that 
would refer to the Sprint (using start/end dates is not very convenient). 
Also, I haven't found a way to filter tasks by Epic/Theme, which might be 
convenient. And there are few other limitations.

Regards,
Alex




From:   "Bohnert, Thomas Michael" <thomas.michael.bohnert at sap.com>
To:     Alex Glikson/Haifa/IBM at IBMIL, "'jhierro at tid.es'" <jhierro at tid.es>
Cc:     "'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:   29/09/2011 01:02 PM
Subject:        Re: [Fiware-wpl] IMPORTANT Clarification



About maintaining sprints.

Recall that the reason for this solution was exactly the possibility to 
maintain sprints associated via associating tasks (per sprint/user story) 
with a tracker (generic enabler/epic/feature/release)




Best, Thomas 
-- 
Please excuse smartphone brevity
 
From: Bohnert, Thomas Michael 
Sent: Thursday, September 29, 2011 11:57 AM
To: 'GLIKSON at il.ibm.com' <GLIKSON at il.ibm.com>; 'jhierro at tid.es' 
<jhierro at tid.es> 
Cc: '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> 
Subject: Re: [Fiware-wpl] IMPORTANT Clarification 
 
Alex,

Yes - we promised to provide 'some level' of transparency in order to 
apease usage areas a bit at the first place, and secondly to maintain a 
means to keep the expectations on fi-ware reasonable. One can hardly argue 
for additional requests if the current workload is close to upper limits.







Best, Thomas 
-- 
Please excuse smartphone brevity
 
From: Alex Glikson [mailto:GLIKSON at il.ibm.com] 
Sent: Thursday, September 29, 2011 11:41 AM
To: Juanjo Hierro <jhierro at tid.es> 
Cc: 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> 
Subject: Re: [Fiware-wpl] IMPORTANT Clarification 
 
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-wpa/attachments/20110929/2fc62a8f/attachment.html>