tag:blogger.com,1999:blog-7412807111368460595.post1959742788603975176..comments2023-08-17T09:13:36.940-04:00Comments on Anecdotal Engineering: "Technical" User StoriesAriel Valentinhttp://www.blogger.com/profile/12207867053388986632noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-7412807111368460595.post-24086027643655934492007-11-08T22:16:00.000-05:002007-11-08T22:16:00.000-05:00Tim,Thanks for your comments.should there be a sto...Tim,<BR/>Thanks for your comments.<BR/><I>should there be a story for how a user gets the end product, and should there be a story for reporting on the health of the product that the user is getting?</I><BR/><BR/>If the project's end product is a CI server, then yes. A sample user story would probably be:<BR/>"As a developer, I want to install the server on multiple operating systems, so that we can run integration builds in various environments"<BR/><BR/>However, if the projects end product is not a CI server, then I must respond with a "no" to both questions. IMO, reporting the health of the project are both at the core of XP's principles and practices. Feedback, Communication, TDD and CI. Teams who do not follow these practices are just not doing XP. The purpose of reporting a distributions health to the customer is to let them know if the team is closer to being "done".<BR/><BR/>The example that you provided sounded more like an implementation detail of a requirement for a user story. I say that because a user story card should only have three elements:<BR/>- role, action, and goal<BR/>"As a frequent flyer, I want to rebook a past trip, so that I save time booking trips I save often"<BR/><BR/>According to Ron Jeffries: <BR/><I>the team releases running, tested software, delivering business value chosen by the Customer, every iteration.</I><BR/>Separating out a user story for reporting the results of the nightly build just does not provide immediate business value. No matter how hard one tries, the end user simply cannot purchase a flight with the JUnit report output.Ariel Valentinhttps://www.blogger.com/profile/15968494425917141273noreply@blogger.comtag:blogger.com,1999:blog-7412807111368460595.post-60776111784961839482007-11-08T00:49:00.000-05:002007-11-08T00:49:00.000-05:00What if you were to explicitly tie a deliverable t...What if you were to explicitly tie a deliverable to the "technical" stories of setting up the Continuous Integration Server and the QA test environment? For example, the CI story might be phrased as such: "Project status reports will be posted to a website generated by the CI server. The report on this website will include a clear indication of whether the product distribution was created successfully, a log of source code changes in the SCM since the previous build, and the results of automated test execution". Similarly, the deliverable from the QA environment could be the product distribution that has been built and packaged to run in a particular environment -- say the Mac or Solaris binaries. I guess it comes down to these questions: should there be a story for how a user gets the end product, and should there be a story for reporting on the health of the product that the user is getting?Tim Myerhttps://www.blogger.com/profile/01514263555690798238noreply@blogger.com