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

[Juanjo Hierro]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-wpl/attachments/20110829/c3c08a90/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jhierro.vcf
Type: text/x-vcard
Size: 429 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-wpl/attachments/20110829/c3c08a90/attachment.vcf>