Dear All,
I think these are useful information for filling our backlogs.
Regards,
Matteo
-------- Original Message --------
Subject: [Fiware-wpa] 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>
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>
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-tools/attachments/20111108/6acf6fa9/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-tools/attachments/20111108/6acf6fa9/attachment.pdf>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Attached Message Part
URL: <https://lists.fiware.org/private/old-fiware-tools/attachments/20111108/6acf6fa9/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: matteo_melideo.vcf
Type: text/x-vcard
Size: 354 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-tools/attachments/20111108/6acf6fa9/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy