[Fiware-cloud] Fw: [Fiware-wpl] Reminder about Backlog entries and some hints

[Alex Glikson]

----- Forwarded by Alex Glikson/Haifa/IBM on 29/08/2011 09:48 PM -----

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:   29/08/2011 04:19 PM
Subject:        [Fiware-wpl] Reminder about Backlog entries and some hints
Sent by:        fiware-wpl-bounces at lists.fi-ware.eu



Hi all,

  This mail is to remind you that you should be about providing entries 
for the FI-WARE Backlog in your respective chapters.

  There are some comments that have applied to the first take on the 
entries within the Data/Context Management WP so that I'm sharing them 
with you because may be they are helpful in collecting your own entries. 
They are, of course, generic:
Try to stick to the formula proposed for goals in the example templates 
("Applications should be able to ..." / "It should be possible ..."). This 
is common practice in Agile.   So, as far as it feasible, and not too much 
artificious, try to follow it.   Following a defined formula, we gain in 
uniformity but, overall it will be easier to extract <performed action>, 
<scenario> and <derived results>.   Note that in Agile, some people like 
to use a cannonical form which is "As a <role>, I can <activity> so that 
<business value>".   We tried just to adapt this a bit to description of 
stories for a software platform, but the notion of "cannonical form" 
itself is something we should try to stick to. 
Chapter field: should be the name of your chapter: "Cloud Hosting", 
"Data/Context Management", "IoT Service Enablement", ...
Source and Stakeholder fields:  You should write "FI-WARE" in here, at 
least for the time being.   Keep Source contact empty for the time being.
Owner and Owner contact: this should be the name of your company (the 
company or companies behind the asset being considered as "baseline"). 
Fill the owner contact with your email for the time being but we'll see 
how to handle this later (we don't want that making entries publicly 
available becomes a source of spam :-)
We mentioned that "name" should be an acronymun (indeed the last part of 
the Id) but I have found itself a little bit useless itself if it is 
actually part of the Id.  Therefore, I suggest that we follow the approach 
of Thales and use it as a short description (should not be longer than 7 
words, preferably 4-5 excluding "and"s "the"s and similar auxiliary 
articles, prepositions, etc) 
The Description field is free.   Put there whatever makes sense to you and 
would be helpful to understand the entry.   Don't hesitate to add URLs to 
complementary documents, standards, whatever you believe may be useful if 
read.   You can upload a document to the docman system at FusionForge and 
then use the link if you wish. 
Regarding the Rationale: at least for entries prioritized with a MUST 
MoSCoW, try to give more info about why "it would have no sense" if we do 
not develop the corresponding feature.   Note that a MUST priority is 
considered to be assigned for features that "If not done, the project will 
be considered a failure".  In other words: the product doesn't make sense 
to you unless it supports that feature.   UC projects may argue that some 
of the features they propose are going to be of a higher priority than 
these ones, so that better you work the rationale for keeping your 
priority.
About the MoSCoW priority:   It is assumed that you are bringing here an 
asset that your company had developed and had plans to keep evolving 
because it is of relevant priority to you.   Therefore, here you are some 
guidelines that I would suggest you to bear in mind when reviewing the 
MoSCoW priorities you had assigned. 
You should assign a MUST priority to features you would plan to address in 
the following 12 months in your product (asset), no matter whether FI-WARE 
had existed or not.   Again, the product doesn't make sense if you are not 
allowed to address this MUST priority.   That's why you had it in your 
roadmap no matter if FI-WARE exists or not.
You may assign a SHOULD priority to features that were in your roadmap and 
you believe were important although perhaps you couldn't address them in 
the next 12 months prior existence of FI-WARE because lack of resources. 
FI-WARE actually gaves you the opportunity to address them. 
You should assign a COULD priority to features you believe are nice to 
have and could be addressed thanks to FI-WARE.    But you are open to 
learn about better ideas that may get assigned a higher priority. 
 
  Hope all these comments become useful.

  Don't hesitate to formulate any question.

  Best regards,

-- Juanjo


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[attachment "jhierro.vcf" 
deleted by Alex Glikson/Haifa/IBM] 
_______________________________________________
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/old-fiware-cloud/attachments/20110829/4642710c/attachment.html>