[Fiware-cloud] Fw: [Fiware-wpl] Following Agile more rigorously

[Alex Glikson]

All, 

See below the renewed guidelines for Agile planning and tracking. 
Please, make sure you are follow the process.

Thanks,
Alex


====================================================================================================
Alex Glikson
Manager, Cloud Operating System Technologies, IBM Haifa Research Lab
http://w3.haifa.ibm.com/dept/stt/cloud_sys.html | 
https://www.research.ibm.com/haifa/dept/stt/cloud_sys.shtml 
Email: glikson at il.ibm.com | Phone: +972-4-8281085 | Mobile: 
+972-54-6466667 | Fax: +972-4-8296112

----- Forwarded by Alex Glikson/Haifa/IBM on 10/09/2012 05:56 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:   03/09/2012 11:23 AM
Subject:        [Fiware-wpl] Following Agile more rigorously
Sent by:        fiware-wpl-bounces at lists.fi-ware.eu



Dear all,

  Once we have made the effort to clean up the backlog, we should catch-up 
and start applying Agile more rigorously.   We at TID believe that some of 
the issues we have experienced regarding delay could have been early 
detected and fixed if we had follow-up Agile and planned Sprints more 
rigorously.

  Chapters should make an effort to start planning minor releases and 
Sprints starting beginning of September. 

  We propose to apply a number of simplifications to the current approach, 
in order to make it lighter:
Leave the public Wiki only to document Epics and Features in the Backlog.  
Note that Testing Plans will be formulated over Features. 
Drop some fields 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. 


  All Chapters should plan the Sprint of one month the week before.   Due 
to the holidays, we will make an exception for this September so that 
Chapters have to have the planning ready by the end of this week.
  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.
  Costs reports will be compared against activities planned during 
Sprints.   If a partner gets not assigned a User Story or a Work Item 
during a Sprint, it means that it is not working on anything, therefore 
cannot justify any cost.
  I hope to be able to review this proposal during our joint WPLs/WPAs 
follow-up confcall this afternoon.
  Best regards,
-- Juanjo

-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es
email: jhierro at tid.es
twitter: twitter.com/JuanjoHierro

FI-WARE (European Future Internet Core Platform) Chief Architect

You can follow FI-WARE at:
  website:  http://www.fi-ware.eu
  facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
  twitter:  http://twitter.com/FIware
  linkedIn: http://www.linkedin.com/groups/FIWARE-4239932



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/old-fiware-cloud/attachments/20120910/919deac3/attachment.html>