[Fiware-i2nd] I: [Fiware-wpl] Reminder about Backlog entries and some hints

[Garino Pierangelo]

Dear All,

here is a mail by Juanjo, containing suggestions to be taken into account when generating the EPICs for backlog (see my request in attached mail for I2ND GEs). I remind you that tomorrow is the deadline to receive your inputs, and there will be also the periodic I2ND confcall (bridge info will be distributed later today).

BR
Pier


Da: fiware-wpl-bounces at lists.fi-ware.eu [mailto:fiware-wpl-bounces at lists.fi-ware.eu] Per conto di Juanjo Hierro
Inviato: lunedì 29 agosto 2011 15:16
A: fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu
Oggetto: [Fiware-wpl] Reminder about Backlog entries and some hints

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
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

[cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non è necessario.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-i2nd/attachments/20110830/745eddd0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jhierro.vcf
Type: text/x-vcard
Size: 443 bytes
Desc: jhierro.vcf
URL: <https://lists.fiware.org/private/old-fiware-i2nd/attachments/20110830/745eddd0/attachment.vcf>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001..txt
URL: <https://lists.fiware.org/private/old-fiware-i2nd/attachments/20110830/745eddd0/attachment.txt>
-------------- next part --------------
An embedded message was scrubbed...
From: Garino Pierangelo <pierangelo.garino at telecomitalia.it>
Subject: [Fiware-i2nd] Assets and EPICs description for I2ND GEs
Date: Fri, 26 Aug 2011 16:05:39 +0200
Size: 202623
URL: <https://lists.fiware.org/private/old-fiware-i2nd/attachments/20110830/745eddd0/attachment.mht>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia.jpg
URL: <https://lists.fiware.org/private/old-fiware-i2nd/attachments/20110830/745eddd0/attachment.jpg>