Have 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 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“Oh drat”, you think. “I’ve got to do a presentation!” Nevertheless, you smile and ask, “Oh, sure—what’s the date?” Presentation Skills for Technical Professionals to the rescue! Out comes Naomi’s Karten’s splendid book. You open it, eager for your sit-down with your personal presentation skills coach. You are easily captivated by Naomi’s clever style and…
Continue readingBy Mary Gorman
In my Stickyminds.com column “Playing at Work: Agile Games Deliver Value” I share game ideas and experiences – the benefits games can provide, selecting an appropriate game, facilitating a game, and designing a winning game.
Designing and Facilitating Agile GamesWhen writing the column I got to thinking how agile principles could provide a basis for good game design and facilitation. I reflected on a recent experience I had at Deep Agile 2010: Empowering Teams with Agile Games. Working in a small group we created a new game, tested it, and retrospected both the game and our design process in less than half a day. We consciously (and some times unconsciously!) were being agile! (To see and learn more about our game, read Michael Sahota’s summary at The Backlog Is in the Eye of the Beholder.)
To clearly communicate the agile-ness of our work and what we learned I did a quick mapping to the Manifesto for Agile Software Development.
Continue readingWhat are good practices for delivering a complex product for a broad global customer with a group of volunteers scattered all over the world?
This is a real-world question for me right now: I’ve volunteered to participate on the Agile-BABOK® (Business Analysis Body of Knowledge) addendum effort. Like the BABOK itself, this addendum can impact the practices of a broad worldwide community of professionals.
Learn From Those Who Have Been There BeforeTwo groups have tackled the problem of using volunteers to deliver an industry standard, so I figured we should “learn before we burn”. One group is the PMI Agile Community of Practice group, and the other is the BABOK Body of Knowledge Committee.
Ideally, learning what worked for these groups, along with their suggestions for what they would do differently were they to do this again, could help the Agile-BABOK addendum effort to start smart: leverage what they’ve found works, avoid or mitigate what didn’t work, and adjust their practices based on their experience.
Continue readingIn my earlier post, How Agile is Influencing the Traditional Business Analyst Role: Part 1, I provided the first set of answers to questions posed to me by a Modern Analyst writer preparing a article on how Agile is impacting the traditional business analyst (BA) role.
Here I continue with the questions and my responses.
What are your thoughts? Do you agree?
Yes, maybe, yes, maybe, yes maybe.
In Scrum, we have the product owner “role.” The PO is perhaps the most important (and burdened) role. The PO must conduct a mix of strategic and tactical activities.
Strategic activities are business or market facing—for example, analyzing the market and business case, defining the product vision and roadmap, developing requirements, adjusting the product backlog, and determining delivery plans.
Tactical activities are delivery team facing—for example, specifying the items to be delivered in each iteration, determining acceptance criteria for them, analyzing dependencies between items, and making tough decisions about what will be built to satisfy a given business need, technical risk, and requirements dependencies. Some great business analysts I’ve worked with pitch in to build and run user acceptance tests.
All this takes a lot of knowledge and many skills, and it consumes a lot of time.
On top of that, to fulfill both strategic and tactical activities on an agile project, the business customer needs experience in product development, along with deep domain and product knowledge.
I’ve coached (and trained) teams working on large, complex products, and I’ve seldom known a single business customer who can do these strategic and tactical activities.
That’s why many organizations turn to talented business analysts for help with the day-to-day, tactical decision making on their agile projects. In other cases, someone who was formerly a traditional business analyst will work out the backlog items, suggest the priorities, and then obtain validation from the business PO.
Continue readingJoin our community and receive periodic tips, stories, and news on agile product management, product ownership, backlog and value management, collaboration, teamwork, and more.