Viewing entries tagged
agile requirements

How does "Documentation" Fit into Agile?

Comment

How does "Documentation" Fit into Agile?

I've been teaching, coaching, and speaking about agile approaches for over 15 years in conferences all over the world. 

In that time, there are a set of questions that everyone seems to be concerned about. I think the top 5 might include the following:

  1. What tools do you recommend we use for tracking our teams?
  2. How do we estimate fixed scope / fixed time projects with agile?
  3. How do I fit my current metrics / KPI dashboard into our agile teams?
  4. Do you really need a ScrumMaster and/or Product Owner? And if so, what do they do?
  5. How does documentation work? We're in a regulated environment and agile doesn't support documentation.

And as time goes on, the frequency of the questions hasn't really declined. So, they're still relevant and indicative of things folks are grappling with in their understanding of agility.

A week or so ago I came across a blog post from Angela Wick entitled - Agile Requirements Documentation - What's Really Needed?

It's the most cogent and common sense answer to #5 above that I've ever seen. And if you know me, when I reference another blog, I usually have something to add or a point or two I disagree with. With Angela's piece, there wasn't a point I couldn't agree with.

It's now my "Go To" reference for folks who are struggling with the questions around -

  • What are agile requirements documents?
  • How much is enough?
  • What to write and what not to write?
  • What should be the focus? 
  • Who writes it?

and any other questions from my clients. Please read her entire blog. You'll find insights and value that will be helpful in your agile journey!

Stay agile my friends,

Bob.

 

 

Comment

Grooming, Maintaining, or Refining your Backlogs – Practices for Success

1 Comment

Grooming, Maintaining, or Refining your Backlogs – Practices for Success

In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition[1]. In both books I took on the topic of Backlog Grooming. 

As it turns out the term “grooming” is losing its luster in the community and terms like maintenance and refinement are replacing it. I believe the latest copy of the Scrum Guide uses the term refinement. So I will try to start using Backlog Refinement consistently throughout this article. That being said, I really, really like the implications of the term grooming.

1 Comment

10 Indicators that you don’t understand Agile Requirements

2 Comments

10 Indicators that you don’t understand Agile Requirements

I presented at a local professional group the other evening. I was discussing Acceptance Test-Driven Development (ATDD), but started the session with an overview of User Stories. From my perspective, the notion of User Stories was introduced with Extreme Programming as early as 2001. So they’ve been in use for 10+ years. Mike Cohn wrote his wonderful book, User Stories Applied in 2004. So again, we’re approaching 10 years of solid information on the User Story as an agile requirement artifact.

My assumption is that most folks nowadays understand User Stories, particularly in agile contexts. But what I found in my meeting is that folks are still struggling with the essence of a User Story. In fact, some of the questions and level of understandings shocked me. But then when I thought about it, most if not all of the misunderstanding surrounds using user stories, but treating them like traditional requirements. So that experienced inspired me to write this article.

2 Comments

Pet Peeves: Getting Agile Requirements ‘Right’

Comment

Pet Peeves: Getting Agile Requirements ‘Right’

I’m sorry but I need to vent. I’ve been encountering these patterns a bit too often lately and I just need to get these thoughts off my chest.

The patterns are these:

  1. Organizations and teams consider it the Product Owners role/job to write every aspect (word) of every User Story. And, if the stories aren’t “complete enough” the team kicks it back to the Product Owner to do a better job.
  2. User Stories are too robust. I’m being kind here. The Product Owner / Analyst writing the story writes a complete requirement (pages, all information) before ever showing it to the team.

From my perspective, these are both agile requirement anti-patterns, you shouldn’t be doing it this way, and I’ll try to explain why. In both cases, I think it goes against some of the very core principles of the agile methods. It’s not changing your Waterfall views and while, you’re saying you’re agile on the outside, on the inside you’re still handling your requirements the same old way.

 

Comment