WEBINAR – Effective Specifications for Agile Projects
Fast turnaround and short iterations require a very efficient and precise specifications process to provide direction. Two emerging practices of specification “by example” and “agile acceptance testing” enable agile teams to specify, deliver and verify better. This webinar will teach you about these practices and how to implement them in your project.
LEARNING OBJECTIVES
- how to ensure a shared understanding of specifications by all stakeholders
- how to manage requirements to provide details just in time & ensure all development team members have enough information to work
- how to ensure that the product built is fit for purpose
- how to know when you are really done with a story
- how to facilitate change in software with live documentation
SPEAKER: Gojko Adzic is a software craftsman with a passion for new technologies, programming and writing. He is the author of several books and online guides on acceptance testing, including Bridging the Communication Gap, Test Driven .NET Development with Fitnesse, and Getting Fit with .NET, and more than 200 articles about programming, operating systems, the Internet and new technologies published in various online and print magazines.
PDUs: 1…..*** PDU information is provided in the recording ***
COST: Free
..
Gojko,
I find that your statements about the problems associated with software development seem to differ somewhat with the most common problems that I have seen discussed in Agile forums. Many of the problems that you mention were the cause for many teams to begin moving from waterfall to iterative or Agile approaches. For example, most Agile teams appear to be doing a good job of matching the tests to user stories – many use a test-driven-development approach where the user stories to be implemented are in fact, the tests. Many Agile teams are moving towards minimizing their Product Backlogs (e.g. the kanban approach), so they would not necessarily be interested in maintaining large effect trees.
Despite this, I believe that the Effect Maps are a good answer to the problematic practice of not retaining “epic” stories in XP and Scrum. I have found that retaining the heirarchy if epic stories does exactly what the effect maps do for retaining the history of “why” we choose to implement certain stories in each sprint.
From this presentation, I’m still not exactly sure what items would be brought into a Sprint Planning session in Scrum.
Huet,
I wouldn’t say that “most Agile teams appear to be doing a good job” simply because I have no data to clam that or otherwise. From my experience, quite a few teams labeling themselves agile actually don’t do this properly. The webinar was my attempt to raise awareness about these good practices. I agree with you that test-driven approach, reducing backlog size etc are good ways to do that and I hope that came through in the webinar.
I’ve used effect maps to provide a global overview of a milestone. Depending on how good the team is with slicing MMFs, level four of the map could be high-level features (“epics”) or stories themselves. Once the team has capacity to accept more items into the backlog, a map will give the business stakeholders an idea what to focus on next and which areas of the map need to be expanded. User stories typically come from level 4 or level 5 on the map. Sometimes we had these detailed on the map in advance, sometimes we would decide that it’s time to put more details into the map from the fourth level down when the time comes to implement a particular feature. At that point we’d get the stories from the map and put them into the backlog. This keeps the backlog relatively thin all the time.