Hi, Thanks for your question. Find my answer below. I'm copying the fiware-wpl and fiware-wpa because I believe that the answer may be helpful for all. Best regards, -- Juanjo On 29/09/11 17:26, GIDOIN Daniel wrote: Dear Juanjo, I have any problem with the definition of AGILE terms and consequently with the deliverables to be provided for tomorrow. Product Backog: The Scrum Alliance provides this definition: “The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements” EPICs Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point. (User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. This is fine, but take into account that saying that something is "high-level" is rather subjective, so that I would drop that part (parts in a definition that are subject to interpretation are not desirable in any definition). What is relevant, and more accurate, is not what you have underlined but the part where you say that a user story "contains just enough information so that the developers can produce a reasonable estimate of the effort to implement it". But I have to say even this definition is incomplete. In order to provide an even more accurate definition, you have to introduce the concept of user story as a requirement covered by a short-time development: "A user story is a definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it and it doesn't go beyond the duration of a sprint" As you probably notice, a fundamental question to answer in order to complete this statement is ... what is the duration of a sprint ... because it would impact the level of granularity in definition of your requirement you have to provide that will give your development team enough confidence to assure that they will be able to cope with the requirement within the duration of a sprint. Remember the attributes of a User Story. Here it is how they relate to the description above: * Independent: A user story should not depend on another user story to get it done. If user story "A" depends on user story "B", then you should only plan "A" in the sprint after user story "B" is solved (in other words, user story "A" will only be addressed in sprint "Sx" only if user story "B" has been addressed in a sprint previous to sprint "Sx") * Negotiable: This is about the "just enough" in the definition above which was not there arbitrarely: you should stop refining a requirement once you have just enough information without delaying start of development until you get all the details solved. There may be still details to solve, but it is assumed that such details can be resolved during the sprint duration without this changing the estimate of the effort significantly (in the unlikely case this happen, the user story should turn back into an Epic, and moved out of the sprint in progress). * Valuable: A user story should include a description of what value it brings if covered by the product (rationale) * Estimatable: This is about being capable to "produce a reasonable estimate of the effort to implement it" * Small: This is about "not going beyond the duration of a sprint" * Testable: This is about providing info in the user story that will help to prepare the necessary test cases that allow to verify that the user story is covered by the product. In other words, the definition of a user story should cover the definition of concrete and measurable points you can test are fulfilled. Of this six attributes, indeed "Negotiable" and "Small" are rather the ones that are unique to user-stories, i.e., don't belong to Themes, Epics, or Features. "Estimatable" is also an attribute for "Features" with the only difference than in "Features" the estimated time should not go beyond the agreed duration of releases (typically 60-120 working days, in FI-WARE 60 working days). It's not an attribute of Themes or Epics. All of them (Themes, Epics, Features and User-stories) may be considered "Testeable" in the sense that a "Feature" would be considered tested once all user-stories in which it gets decomposed are tested. Similarly, an Epic would be considered tested once all Features/User-stories in which it gets decomposed are tested. "Valuable" is an attribute of all of them too, but there the explanation is pretty simple ... Agile is about developing things that really provide value. For you: • Product backlog: It’s about keeping track of “work to be done”, and keep it described in a way that makes sense to both users and development teams • User Stories are simply description of “work to be done” that is detailed enough as to be addressable by a development team along the duration of a sprint. • EPICs relate to “work to be done” you have to further split before being addressed in the next sprint” My experience is that many people who approaches Agile for the same time get scared because they believe that the concepts are "radically new" to anything they know before. But the true fact is that they aren't (in my honest opinion). The "work to be done" by a team who is developing a product is actually that: implementing the product. So there is absolute no contradiction between the statements you extract from me and what is said above. Actually, you could rephrase the definition as to say: "A user story is a definition of a requirement, containing just enough information about the work to be done in implementing the requirement so that the developers can produce a reasonable estimate of the effort to carry out that work and the duration of that work doesn't go beyond the duration of a sprint" I introduced the reference to "work to be done" because many people who have strong planning management skills understand then better what Agile is about and find that it is not that different compared with the usual task many of them use to carry out about keeping a spreadsheet with which they follow-up "work to be done / in-progress". I am not familiar with the Agile but I feel that the definitions are very different. Also I have trouble understanding what I need to deliver about it tomorrow. Could you enlighten me with a very specific example. I hope that this explanation is helpful. Regarding examples, I believe that I have given enough examples (take a look at the templates I distributed in August where there were examples of Epics and User Stories) ... but, nevertheless, this is another point to take into account: Don't become obsessed about whether an entry you have produced should be labeled as an Epic or as a User-story: * There will be Epics that will be like in the frontier. Shift them to become user-story or still keep it as an Epic is pretty simple: just ask your development team "can you give ensure me that you would be able to implement what is needed in the product to cover this entry in less than one month ?" If the answer is "no" or simply "well ... I would need more info" ... Then it's not a user-story and should remain being an Epic. * There will be entries you may wrongly label as user-story because, among other things, the development team believed they had enough information to implement what is needed in the product to cover it at the time the planning of the current sprint took place. But then ... during execution of the sprint they realize that there was much more information that was needed ... In such a case, you should stop implementing it and try to answer all the question so that, at least, it becomes a true user-story (you may then decide to address in next sprint) or a better documented Epic in the backlog. You may even realize that such user-story may need to transform into a user-story you can actually finish in the current sprint but an additional set of user-stories and Epics for following sprints. Best regards Daniel ________________________________ 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-wpl/attachments/20110929/df9d7521/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy