[Fiware-data] Fwd: IMPORTANT UPDATE/HINTS on Selection of Features for the 1st Minor Release and planning of 1st Sprint

[Juanjo Hierro]

Hi all,

  This is the email I sent to WPLs/WPAs today.   Please read it carefully.   It elaborates on what we already commented during our follow-up confcall this morning.

  Cheers,

-- Juanjo

-------- Original Message --------
Subject:        IMPORTANT UPDATE/HINTS on Selection of Features for the 1st Minor Release and planning of 1st Sprint
Date:   Fri, 04 Nov 2011 14:02:51 +0100
From:   Juanjo Hierro <jhierro at tid.es><mailto:jhierro at tid.es>
To:     fiware-wpl at lists.fi-ware.eu<mailto:fiware-wpl at lists.fi-ware.eu> <fiware-wpl at lists.fi-ware.eu><mailto:fiware-wpl at lists.fi-ware.eu>, fiware-wpa at lists.fi-ware.eu<mailto:fiware-wpa at lists.fi-ware.eu> <fiware-wpa at lists.fi-ware.eu><mailto:fiware-wpa at lists.fi-ware.eu>


Hi all,

  We definitively need to close the selection of Features for the 1st Minor Release of FI-WARE as well as the planning of the 1st Sprint.

  We should have closed it by end of October but unfortunately we are delayed.   Therefore, we have to take the necessary corrective actions.   This mail is intended to put this actions in place so that we can recover these few days of delay and get back on track.

  Everything should be fixed by Nov 10th at the latest.    We will do this at the price of making the first sprint a bit shorter, still planning it to finish by end of November.   On Nov 10th, it should be clear what are the Features selected for the 1st Minor Release of FI-WARE and what are the backlog entries to be addressed in the 1st Sprint.   That information should be visible on your tracker.   Note that November 10th is the date at which we have told our PO that everything should be available on the Wiki and FusionForge environment.

  Now, following the actions/recommendations to implement/follow (some have already been tackled by some of you, but I'm summarizing them here for the convenience of all).   Don't hesitate to raise any question or doubt that you may have.    Please share them with your teams.


Regarding Selection of Features for a given GE:

  Features may be considered just as a kind of Epic you believe you understand enough (i.e., you own enough detailed info describing the functionality of the Epic) as to feel confident that can be addressed in the duration of a release (duration of releases, also named as minor releases, are three months, don't confuse with usage of the term "release" in the DoW that comprises several releases and we have started to name as "major release").

  You may hay identified a number of Features following the above criteria.

  However, some of you have only identified entries that you have labeled as Epic so far.   If so, the first exercise I would ask you to do is to review the list of Epics you have and try to ask yourself the following question ... "Is this a functionality I really understand and have enough information about as to feel confident that could be addressed in 3 months ?"   If your answer is "yes", then simply label the Epic as Feature and change the entry both at the Wiki and the tracker accordingly.

  It may happen that the Epics you have identified are still at a very high-level though.  Therefore, you cannot guarantee that you will be able to address them in any.   Thus, you need to refine them and this will be work to be done.   Those Epics cannot be selected as Features, of course.   I would suggest that you try to make some progress refining them until November 10th and try to find out whether you can derive more detailed entries from them and check whether some of them can be labeled as Features.    But those entries you believe cannot qualify as Feature because they are still too high-level should be kept as Epics.

  The first minor release is scheduled to finish by end of January.   I know that we have considered finishing it by end of February but after feedback from some of you, let's keep it to finish by end of January.

  Once you identify a number of Features, it's a matter of deciding whether you feel confident enough to assign it to a particular minor release within the first major release.   If so, you should assign it a ReleaseId to the ticket associated to the Feature on the tracker.

  We will adopt the following convention for identifying minor releases in FI-WARE (i.e., for the values of ReleasesId fields on the tracker):

    FIWARE.Release.<x>.<y>

  Where <x> is the number of the major release the minor release is associated to
  Where <y> is the number of the minor release, within the <x> major release

  Note that you may not yet feel confident about what release will be the release in which you will address a particular Feature.   If so, simply don't assign a ReleaseId to the corresponding ticket.   Anyway, bear in mind that, when referring to Features in releases other than the current minor release, you are just setting up an expectation.   Expectations may change a bit and we may decide to update the list of Features we plan to address in the second minor release while developing the first minor release.   Adapting the planning over time is what Agile is all about.

  If by November 10th you haven't identified any Feature and you still only have Epics, don't panic.   See next section.


Regarding planning of 1st Sprint:

  Some people have shared the feedback that they feel like they are not still in the position to identify a relevant list of User Stories or even Features.   They still need to work on the set of Epics they had currently identified.   How can we show we are doing some work in the course of the first sprint and be able to follow-up progress ?

  After thinking a bit on the matter, I have decided to introduce the concept of "Work Item".   Work items refer to work to be done in the course of a sprint, trying to meet a concrete goal.   It may relate to work to be done in order to refine an Epic (or a feature) and derive actual Features (or User-stories) derived from it.   In general, any work you need to address to progress development but may be difficult to express in terms of "functionality supported by the product".

  This I hope will help you to declare things to be addressed in the first sprint (and subsequent sprints) in a more natural/intuitive way.

  "Work Items" is not something I had invented myself.   It was already identified as a special kind of backlog entries by some Agile authors.   Indeed was identified by Dean Leffingwell in the paper I had already sent to you some time ago.

  The reason why I feel reluctant to introduce these kind of entries in our definition of Backlog was that I was afraid about the explosion of entries in the Wiki.   Besides, some of these work items may relate to activities that we may wish to keep at confidential level, just shared among FI-WARE partners.  At the end of the day, users (application developers in our case) should just need to know about functionality we plan to develop in GEs.

  Now I see the advantages that introducing these "Work Items" will bring to some chapters, and definitively they will help us to move things forward and monitor progress.   So let's go for their introduction.

  However, trying to minimize overhead what I believe we can adopt as a formula is that these Work Items just need to be registered on the tracker and we don't need to create a detailed entry on the Wiki.   I feel like this is a good compromise and have the following advantages:

 *   We will keep on the public Wiki only that information that is relevant in terms of description of the functionality to be supported by GEs.   At the end of the day, this is what is relevant from an user (app developer) perspective, so there is no need to overflown the Wiki with additional, so fine-grained info.
 *   Work Items would exist on the trackers (which is the place where you can get the complete view of a backlog) and trackers linked to chapters are private to chapter members.   This will be helpful

  Given said the above, the task to be done until Nov 10th is to get a good list of User-Stories and Work Items that help to describe what you will do during the first sprint (ending Nov 30th).   Hope that this will mean a more clear goal and then you will be able to provide some "meat to eat" by then.

  We will adopt the following convention for identifying Sprints in FI-WARE (i.e., for the values of SprintId fields on the tracker):

    FIWARE.Sprint.<x>.<y>.<z>

  Where <x> is the number of the major release where the sprint is planned
  Where <y> is the number of the minor release, within the <x> major release, where the sprint is planned
  Where <z> is the number of the sprint




________________________________
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/old-fiware-data/attachments/20111105/15b0d13f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a-lean-and-scalable-requirements-information-model-for-agile-enterprises.pdf
Type: application/pdf
Size: 1463988 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20111105/15b0d13f/attachment.pdf>