Hi, I would like that you sent a explicit acknowledge of reception of my previous mail as well as confirmation that you are on track working on providing the first set of EPICs by August 16th. Thanks in advance, -- Juanjo On 10/08/11 18:52, Juanjo Hierro wrote: FYI. Hope it will be helpful for the work of each of you taking care of entries linked to a GE in the backlog. This input, together with the detailed description of next steps provided (previous mails sent to the WPLs and WPAs and forwarded to you), should gather all the information that is necessary so that you can start to elaborate the entries linked to EPICs for the assets we have agreed to adopt as baseline for development of the reference implementation of some of the GEs in our chapter: * Publish/Subscribe Broker GE: here we intend to develop two different reference implementations, one based on the asset from TI and another one based on the asset from Orange (unless they agree to join developments at some point). They should coordinate the creation of entries in the FI-WARE backlog for this GE, under leadership of TI (Boris). Note that there may be a) entries that are just relevant to TI's assets b) entries that are just relevant to Orange's asset c) entries that are jrelevant to both * Complex Event Processing GE: we intend to develop a reference implementation based on the asset from IBM. Responsible: Guy * BigData Analysis GE: we intend to develop a reference implementation based on the asset from Telefonica I+D. Responsible: Juanjo (indeed, another person will lead this who has just been incorporated and will catch up during August) * Multimedia analysis GE: we intend to develop a reference implementation based on the asset from Siemens. Responsible: Peter * Meta-data preprocessing GE: we intend to develop a reference implementation based on the asset from Siemens. Responsible: Peter * Query Access GE: we intend to develop a reference implementation based on the asset from Siemens. Responsible: Peter. See notes below. * Localization Platform GE (SLP component): we intend to develop a reference implementation based on the asset from Thales. Responsible: Remi. See notes below * Semantic Annotation GE: we intend to develop a reference implementation based on the asset from TI. Responsible: Boris * Semantic Application Support GE: we intend to develop a reference implementation based on the asset from ATOS. Responsible: Tomás ? Target milestone is August 31st, when we should have been able to gather a complete and comprehensive set of EPICs (see email below). As an intermediate milestone, I would like you to send a first take on your side by August 16th. This will allow me to review them and provide some feedback. Unless you believe that we need to have a follow-up confcall this week, I would skip it for this week. If you have any doubt or concern, please don't hesitate to share it over the email. This would be more suitable for me during this period until I get back to the office on August 22nd. Best regards, -- Juanjo -------- Original Message -------- Subject: [Fiware-wpa] Hints and examples about entries for the FI-WARE backlog Date: Wed, 10 Aug 2011 18:06:46 +0200 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, One of the action points that were agreed had to do with providing some detail examples of what the entries for an EPIC and a User Story (or Story, for short) in the FI-WARE backlog. Please find enclosed a spreadsheet where I have included two separate sheets describing: * The template to be used for entries in the backlog. This is an update of the one you already had where I have addressed some points that were unresolved or required some clarifications. I have found also the need to add a new field (Detailed Status). * An example of an EPIC * An example of an User Story The examples are not "official". I just elaborate them on my own (although the EPIC was based on an initial proposal made by Fernando López from TID). They just pretend to serve as example of the level of "granularity" associated to an EPIC compared to a User Story in an Agile backlog. What can be considered at the level of "user story" according to Agile ? Well ... there is no a black or white frontier between things nor a mathematical formula you can apply and then determine when something should be considered an EPIC rather than a User Story. As mentioned in the presentation on Agile we made at the FI-WARE kick-off meeting, User Stories have to comply with "INVEST" properties which mean they should be "Independent, Negotiable, Valuable, Estimatable, Small and Testable". Some resources that may be helpful in finding out what we mean by INVEST properties can be found at [1], [2] and even [3] but in general: * Bear in mind that User Stories have to be something "Small" as to be affordable in a Sprint. Sprints should be of a maximum of two months in FI-WARE, unitary tests included (I'm even seriously considering to make them shorter, of about one month, therefore closer to the spirit of Agile). In general, something that would go beyond one single sprint should be considered an EPIC. * It should be also detailed enough so that you can say "I understand what I want well enough that I could think how a test for it could be designed." This is what means it should be "Testable". * User stories also should be "Estimatable" meaning that it should contain enough information enabling a developer to make a rough estimation of how much it would take to develop it (and shouldn't go beyond the time limits of a sprint :-). In our case, we are supposed to bring on the table tangible assets per GEs. Therefore, "Estimatable" means that the corresponding development team should be able to answer you how much would it take to implement the user story you are providing. Therefore, you can make a simple test: take one of your entries, go to the teams, and ask them "how much effort (roughly) would it take ?" ... if they give you answers like "unless you give me more details, it's simply impossible ... what you provide is too vague", then you don't have a user story for sure but probably an EPIC. * They don't need to have ALL the details nor have everything closed. There should be details that may be worked out while developing it (again, bear the duration of sprints in mind, i.e., maximum between 1-2 months). You shouldn't enter into that level of detail at which you are probably wasting time and unnecessarily delaying development. But good developers are able to provide accurate estimations without knowing all details. This is why they should be "Negotiable" (detailed description may vary/be-refined over time even during development but without this implying a relevant deviation from the original estimation) "Independent" and "Valuable" are also relevant but I guess there may be many EPICs that would also cope with those properties. That's why I would make emphasis on the previous points. Some references (but you may find much more, just search for INVEST properties for User Stories in Agile or discussions on EPICs vs User Stories): [1] - http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ [2] - http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest [3] - http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29 Themes, are much more high-level or abstract than EPICs. The frontier between Themes and EPICs is also fuzzy, but is not that relevant as the frontier between EPICs and User Stories because this last frontier is what matters to know when you may stop refining. Indeed, we may adopt a convention regarding what to call Theme and what to call an EPIC. For example, we may map the notion of "Theme" to the notion of Generic Enabler in FI-WARE. Therefore, there would be a Theme linked to the "Publish/Subscribe Broker GE" which establishes as a goal that "Applications should be able to publish data and subscribe to data of their interest". The "target usage" text in the FI-WARE Product Vision / High-level Description deliverable for a given GE may well work as the content for the description of the corresponding Theme. Given said this, don't feel too frustrated if you are not able to identify too many User Stories in a first shot. I believe that we should feel confident if we end August with a complete and comprehensive set of EPICs per Generic Enabler. Then, during September, we may focus in trying to derive a number of User Stories from those EPICs that will enable to plan the first sprint in FI-WARE (which we should be able to start by early October) Please remind that we are supposed to rely the development of the reference implementation of FI-WARE GEs in a number of assets. We should concentrate on what will map into development tasks on those assets (so that they can integrate with other assets, comply with the final standard open royalty-free specification of interfaces we want them to provide, incorporate any function that we agree a target reference implementation must/should offer but our asset still do not offer). Don't focus on describing things already supported by an asset. Remember: backlog = work to be done. Review my previous mails on the matter if you have any doubt. Please share this with your teams. And don't hesitate to bring on the table any doubt, concern or comment you may have. Let's share them and share the answer. Last but not least, please send back two separate responses: a) first to Thomas and me, a response confirming that you have received this email b) later, to the fiware-wpl and fiware-wpa, an email confirming that you have read it and you feel like there is no essential obstacle for moving forward. If you have any initial questions/doubts/comments you would like to share at the time you send the response, please do so. 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 ________________________________ 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/20110811/d9cd6180/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/old-fiware-data/attachments/20110811/d9cd6180/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy