Dear colleagues, This is a reminder that you should devote these last days until end of October to identify/select the User Stories that will be addressed in the first development sprint of FI-WARE. You should also define the Features that you plan to address during the first release of the project. Here, we have a small issue because we defined (minor) releases as 3 months long and we wanted to split the first major release of FI-WARE (scheduled to finish by end of Abril, according to the DoW) into two (minor) releases. I had proposed finishing the first release by mid February during our last joint WPL/WPA follow-up confcall but now I believe like it would be better if we close the first (minor) release by end of February (given the fact is the first) and keep the second (minor) release a bit shorter. Some of you still have some doubts about how to identify Features. On the other hand, you have already identified a bunch of Epics so it seems like there is definitively no problem identifying Epics. Well ... if that is the case then I tell you that It's a matter of just naming as Features those Epics you expect to address in the first minor release (scheduled to be finished by end of February as I have just said). As simple as that. Note that being able to state that you expect a given functionality described as an Epic to be implemented in your product by the end of a release simply means that you have enough information about the functionality as to feel confident that you will be able to refine it to the level of User-Stories which, in turn, can be addressed in development sprints, all during the course of the first (minor) release. But that is actually the definition of a Feature. Therefore, the proposal I would make is that you simply review the Epics you have already identified and select those you expect/plan to address by end of February (or earlier). Then change those Epics and name them as Features. That's all. It will imply updating the Id both at the Wiki and the tracker. Also the location in the proper section at the Wiki. I know. But it's not a big deal. Those Epics you don't turn into Features will of course remain being named as Epics. Why are we then dealing with Features in addition to Epics ? Because it gives hints about what functionality we expect to address within a certain period o time and this is important for the overall management of the project and for interaction with customers. Particularly the UC Projects, who need to know what functionality is going to be available when, so that they can plan their developments better. Other than this, you may think on Features as just Epics you have committed to address before some given date. Hope these hints help you to identify the Features for the first (minor) release of FI-WARE. Don't hesitate to ask if you still have doubts or questions. Please find enclosed a paper from the recognized Agile expert Dean Leffingwell where a more elaborated description of Epics, Features, User-Stories is given. I hope it will also be helpful. DON'T FORGET: Try to identify the User-Stories for the first sprint and the Features for the first release no later than end of October. Cheers, -- Juanjo Hierro Chief Technologist on Software Technologies Telefonica R&D Labs email: jhierro at tid.es<mailto:jhierro at tid.es> phone: +34 91 48 32932 www.tid.es<http://www.tid.es> twitter.com/JuanjoHierro Oeste 1, Planta 5. Distrito C Ronda de la Comunicacion s/n Madrid 28050 Spain ________________________________ 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/fiware-wpa/attachments/20111024/4b0d709d/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/fiware-wpa/attachments/20111024/4b0d709d/attachment.pdf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy