[Fiware-i2nd] Simplifications to allow following Agile methodology more rigorously

[Garino Pierangelo]

Dear All,

When aligning all the entries in the I2ND tracker and planning the current Sprint, you should take into account the following rules and simplifications that can now be applied (they were proposed one week ago, and they are currently effective), to ease following the Agile methodology (while being more rigorous in applying it).

  All Chapters should plan the Sprint of one month the week before.

  Planning should translate into:

 *   A number of User Stories in the Backlog (tracker) become planned for development during the Sprint (they get assigned the corresponding Sprint Id)
 *   A number of Work Items that are also planned to be carried out during the Sprint (either selected from list of work items pending in the backlog or identified as new during planning).  Examples of work items are:
    *   Work required in order to deal with refinement of a Feature into User Stories
    *   Work required in order to deal with refinement of a Epic into Features (and maybe some work items)
    *   Work to be done in the FI-WARE Testbed (e.g., deploying an update of some GE)
    *   Work to be done in the FI-WARE Catalogue
    *   Contributions to development of deliverables in WP2 (e.g., Architecture Description, Technical Roadmap, Open Specifications, etc), WP10, WP11 or WP12
    *   Participation in some workshop with some UC project
    *   Solution of some ticket(s) issued in the FI-WARE Global Support tracker
    *   Peer Reviews
    *   etc

  Work items may typically be identified and planned by the WPL.   It is expected that work items may help to capture and  follow-up Action Points identified within a WP.  --> In I2ND we extend the creation of WorkItems to Task/GE Coords (in some cases it could be done by the developers too).
As you see the Work items allow to also keep track of those activities we are taking care of in these days (e.g. the peer review of other chapter deliverables), so it is easier to have a snapshot at any time of what is done (by whom), so please use them accordingly.

In case of doubts you can have a look at the guidelines to create new entries at wiki page How to create entries in the "Backlog Management" Tracker of a FI-WARE Chapter<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/How_to_create_entries_in_the_%22Backlog_Management%22_Tracker_of_a_FI-WARE_Chapter>

Moreover, the page Releases and Sprints numbering, with mapping to calendar dates<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Releases_and_Sprints_numbering,_with_mapping_to_calendar_dates> shows the naming conventions for assigning Release and Sprint IDs to tickets.



Further enhancements to make it easier following the methodology will be:


 *   Leave the public Wiki only to document Epics and Features in the Backlog.   Note that Testing Plans will be formulated over Features.  -> This means that User Story entries will be removed from the 'Materialising' wiki, see below!
 *   Drop some fields (of tickets) documenting Epics and Features.  Candidates are:
    *   Scope (always Generic Platform)
    *   Relative Priority
    *   Source (doesn't add value over stakeholders+owner)
    *   Rationale (difficult to fill)
    *   Version (Mapping of Features/Epics into releases should be captured on the Technical Roadmap.   A field here would introduce risks of inconsistencies.  If it were related to version of the contents of the entry, we would be adding complexity over the history that is already controlled by the wiki ... is strictly needed or was just nice to have ?)
    *   Enabler (can be determined from the Id)
 *   Keep User Stories documented only at the level of the trackers.   Note, though, that this may require to add custom fields (e.g., description of how a user story will be tested), so that we would like to hear others' opinions.
 *   Work items would remain also documented only at the level of the trackers.

Hope this helps completing the job more easily.

BR
Pier



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:00000000000000000000000000000003 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/20120911/60d4447e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia2.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia2.jpg
URL: <https://lists.fiware.org/private/old-fiware-i2nd/attachments/20120911/60d4447e/attachment.jpg>