I’m pleased to share with you an “author cast,” a podcast interview of me by Yaaqub (Yamo) Mohamed of The BACoach.
Yamo’s interview got me thinking and reflecting on my own professional learning journey and dig into the two books I’ve written (so far 😉 ).
Continue reading
I’m thrilled to be collaborating with Janet Gregory, co-author with Lisa Crispin of Agile Testing, on a workshop entitled “Agile Requirements Exploration with Tester Collaboration” at Agile 2011 Conference and STARWEST.
I believe that there is a lot of cross-fertilization benefit to be gained when people with skills in different disciplines collaborate closely toward shared ends. This is very true for the disciplines of testing and business analysis. The tester mind-set is crucial for verifying requirements. The business analysis mind-set is crucial for validating requirements.
Continue reading
I was recently interviewed by SearchSoftwareQuality editor Yvette Francino about this week’s Business Analysis and Requirements Workshop at the Better Conference/Development Conference this week in Las Vegas, Nevada (6-7 June, 2011).
Yvette asked me to explain the logistics, if we would be emulating gathering requirements for a particular project and if the workshop be relevant regardless of domain area. Here are my answers: As conference chair,
Continue reading
In a prior blog post, you learned about the in-progress book Mary Gorman and I are writing. We are thrilled to have our workshop proposal for the Agile 2011 Conference accepted. The workshop will incorporates elements of our book. Here’s our YouTube video on The Product Partnership submission.
By Ellen Gottesdiener and Mary Gorman In September 1977, the TV sitcom Happy Days had über-hip Fonzie, clad in leather jacket and swimshorts, water ski over a shark to prove his mettle—and at that moment even diehard fans knew that the show was past its prime. They were right. After that episode, ratings plummeted, and the…
Continue readingHave you been in a situation where there’s no documentation, yet you’re expected to understand functionality? Trial transactions and observing behavior is one answer. But understanding context is also important. Sue Burk suggests creative solutions in her expert response.
Continue readingMary Gorman and I are in the midst of writing a book. The title is still a WIP (work in process). A couple of contenders are “Agile Product Needs: <subtitle1:> ” and “The Agile Product Partnership: <subtitle2>”. We’ll be looking for your help on settling on a compelling title – stay tuned, we can use…
Continue readingWhat Tough Agile Analysis Questions Do Business Analysts Need Answered? This is the question I posed to the participants in a facilitated workshop at the Building Business Capability Conference (BBC) 2010 this past fall. The BBC conference, held in the Washington, D.C. area, was the first official IIBA ® conference. It offered tracks for business…
Continue readingMary Gorman and I wrote an article on analysis debt Better Software. In it, we said that, like technical debt, teams can incur analysis debt by either ignoring analysis (a potential pitfall of agile teams) or overinvesting in analysis (a potential pitfall of traditional teams). In a private exchange, one article reader took me to…
Continue readingBy Guest Blogger Rob Elbourn, Scrum Team Lead working at a major financial concern in UK. Visit Rob’s Agile78 Blog
I recently attended the “Agile Requirements by Collaboration” presentation at Skills Matter lead by Ellen Gottesdiener from EBG Consulting. Here are some of the main points I got from it.
Ellen described how collaboration needs to happen on several different levels of granularity along the way requirements are viewed on agile projects– the product (which establishes the product or portfolio roadmap), the release and the iteration (or work-in-progress).
Exploring these views can occur in several different facilitated workshops, from the roadmap workshop, to the release workshop to iteration workshops. The corresponding requirements that are clarified or driven out from these workshops also appear on different levels – boulder, rock and pebble.
The idea is that the pebbles form your user stories and are driven out at the level of the iteration workshop. Projects can encounter rock sized requirements at the iteration level and suffer a time delay as new pebble requirements are chipped off from them. This brings to question the level of “doneness” for a user story.
Continue reading