Sounds good. One concern is the vacations that most of the people are going to take in the upcoming 2 months -- making it more difficult to make progress with the WP-wide discussions, which could affect the M5 deliverable(s). Regards, Alex 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: 10/08/2011 07:10 PM Subject: [Fiware-wpl] Hints and examples about entries for the FI-WARE backlog Sent by: fiware-wpl-bounces 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[attachment "Backlog entries examples by TID 11-08-09.xls" deleted by Alex Glikson/Haifa/IBM] [attachment "jhierro.vcf" deleted by Alex Glikson/Haifa/IBM] _______________________________________________ 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/fiware-wpa/attachments/20110811/03629499/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy