Agile Acceptance Criteria - a basic approach

I’ve been hearing a bit of confusion about acceptance criteria lately and I wanted to clarify a couple of things.

Ultimately, the point of acceptance criteria is to establish the definition of done. We talk about defining done in Agile so that teams know exactly what to create. We try to, well let’s just say, “control” gold-plating by offering this definition of done. I believe that in using the “Given, When Then” format, we are also helping testers determine when to begin and end the testing for that specific independent feature. 

So the format would look something like this:

User Story: As an executive, I want to be able to filter the dashboard by department so that I can isolate data by specific department.

Acceptance Criteria: Given the Executive Dashboard default view, when I select the department drop-down, I have the ability to select a specific department so I see only that data throughout the dashboard.

In grooming sessions/workshops, I would expect this basic information to garner discussion and questions. The result of the first grooming session should be perhaps a sketch as well as some questions such as:

• ·         “Hey Product Owner, does the Executive need to be able to Multi-select several departments?”
• ·         “How about grouping by division?”

During this discovery, we might find out from the technical influence in that Grooming Team that coding for Multi-select would make this story much more complex and maybe even too complex to complete in only one iteration.

This conversation would then offer the Product Owner the opportunity to decide to make the multi-select option a second story.

From the testers perspective, the ‘Given’ (Given the Executive Dashboard default view), has established where the testing begins and help determine what acceptance tests to create. So more discussion is likely going to happen and assumptions will be documented, such as security: who can access the Executive Dashboard, etc. Additionally, this direction helps testers go back to look at anything they might have missed that should be a regression test.

Always consider where the testing should begin (Give a state) and where it should end (So that a specific result is experienced). Conditions of Satisfaction should include assumptions and alternatives.

All Managers are not necessarily your Agile leaders

“Leadership is the ability to influence or inspire others to achieve shared goals.”

Dees, et al., 2007

When an organization transitions from traditional project management to using Agile Methodologies, one of the first things I see most of my clients do is have their traditional managers basically switch titles to become Scrum Masters.  Asking someone to transition from a manager position to a leadership role is difficult at best. Especially when we do not take the time to define what is needed for that leadership role; much of which has to do with corporate culture, but also with defining other aspects such as discipline, human and emotional intelligence, ethics, establishing trust, Learning etc.

This sounds easy, but it is not. Think about what defines leadership and how you would be able to quantify any definition. 

And then there is the holistic part of quantifying good leadership. I’ve been very fortunate in my life to have experienced excellent leadership. As a child, I had good leadership and didn’t know it, as a United States Marine, I experienced good and bad leadership, and the results were self-evident. As a professional in the civilian world, I have had great managers, but few great leaders.

When I look back and try to define good leadership, the first thought that comes to mind is “they’ve got my back”. Regardless of the decisions I have made, a good leader was there to guide me and protect me. I think that a good leader will always try to encourage everyone to take the initiative and help guide through the judgment. 

This leads to the second immediate thought I had when thinking about good leaders: “They let me use my own ideas to accomplish the goal”. So, these leaders usually came to me with a goal and let me figure out how to achieve it. And when I “failed”, I really didn’t. I just had an iteration of prototyping. It was ok. As long as I learned from it and improved. Sound familiar? 

So, my message is to be more thoughtful to the leadership roles you are seeking and those you put into those roles. Good managers are typically very organized and can whip trough administrative activities quickly and accurately. Good leaders can achieve results and growth in their teams.

It’s not just about iterative delivery and stand-ups…

One of the precepts of Agile Project Management is the concept of delivery through disciplined, self-organized, cross-functional teams. Somehow, “self-organized” has changed to “self-managed” in some organizations. I have often used the following analogy: If I decided to purchase and operate a restaurant, I would fund the purchase, perform the marketing research, and then decide on the atmosphere and style. I would then carefully educate the kitchen staff on what we are going to accomplish and proceed to let them decide on how they are going to go about delivering that menu. One thing that I did not say is that I would essentially let the kitchen staff “wag the dog” by dictating the hours of operation, the decor, or even perhaps the size of the menu. However, if I am a smart business owner, I would certainly seek and heavily consider their suggestions and do my best to gain their buy-in to my vision.

Now, this scenario would be easier if I started from scratch and brought in a new staff. Let’s say that I purchased a restaurant and all of its assets, including the staff. Then I went about all of the activities I mentioned above. Unfortunately, the odds are that I’m going to have some staff members that perhaps are not as talented as people thought, or we might find a person or two who do not carry the same level of work ethic. Which means, that I need to make some changes. The sooner we can find these weaknesses, the sooner I can make these changes.

Now let’s go back to Agile: we need to remember that transitioning to Agile Methodologies is in fact an paradigm shift in the corporate culture (that’s, right…the entire corporate culture). Which means that besides providing for, instituting, and supporting the technical aspects of Agile Development[1]; and besides providing great agile leadership, the business needs to look holistically at the fit and feel of the staff, and be prepared to replace those weaknesses with stronger assets. 

Now, don’t exaggerate my comments here. I am not saying that everyone needs to clean house; I merely stating that every business should want the all-star team. Think about the changes to hiring practices. We should always be hiring for fit as well as hiring for skill. This also means the aligning all the internal organizations (Marketing, IT, Sales, Professional Services, etc.) to culturally fit is crucial to meeting your business objectives, and therefore, to your success.

---

[1] More powerful language such as Python, Ruby, etc.; More flexible architecture; Acceptance Tests, Test Driven Development, Unit Tests, Refactoring, Source Control, Knowledge sharing, coding standards, collective ownership, continuous integration, etc.