Inspired by artwork by Pictofigo
We’ve all seen it happen. Though we try to show organizations the benefits of using a mature agile delivery framework, we still run into roadblocks. Though the status quo is killing their organization, some barriers to further Agile adoption happen way too often among organizations that need it most. I recently had a client ask me to introduce the elephant in the room. I was asked to actually list some common barriers others have dealt with. I want to thank our friends over a VersionOne for distributing an annual survey of the Agile space. One of the questions? What is preventing you from further agile adoption? Within the last published survey, 4048 people responded and they were able to vote for more than one barrier. The responses may sound familiar.
Barriers of Agile Adoption
|1||52%||Ability to change organizational culture|
|2||41%||General resistance to change|
|3||35%||Trying to fit agile elements into non-agile framework|
|4||33%||Availability of personnel with right skills|
|8||22%||Confidence in the ability to scale|
|9||14%||Perceived time to scale|
Did they miss any in the list? How did you overcome your barrier?
Originally posted at LeadingAgile
What is it?
The purpose of backlog refinement (grooming) is to make improvements to the product backlog. Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is.
Who does it?
Backlog Refinement is a collaborative effort involving:
- (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal
- (Optional) representative(s) from the Management Team – clarify the high level priorities
- (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items
- (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed upon product backlog items. It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.
When is it?
Before development of a user story in the current sprint (iteration), generally sometime during the previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale. Depending on the delivery rate of your teams, you should be meeting once or twice a week to review the backlog.
Before You Begin
We need to ensure:
- The product backlog is top-ordered to reflect the greatest needs of Management Team and the Product Owner Team
- Candidates for grooming include stories identified as not ready to complete within the next sprint or will require multiple days of research
- Epics, features or other items on the Management Team roadmap are reviewed periodically
The product backlog can address anything deemed valuable by the Product Owner Team. For the purpose of sprint planning, when using Scrum as the delivery framework, product backlog items must be small enough to be completed and accepted during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner team.
Backlog items must be completed in a single sprint or split into multiple user stories. While refining, give stories an initial estimate to see if they are small enough. If not, split them. The best way to split product backlog items is by value and not by process.
All stories require acceptance criteria. Without it, you can not define the boundaries of a user story and confirm when a story is done and working as intended. Ensure acceptance criteria is testable. This is what your testers should be writing tests against.
Rewrite Written Stories
Ensure the user story format is consistent, INVEST criteria is being met, and is written from a business not technical perspective. Know who the customer is. It may not be an end user. Rather, the story may be for something like a service, to be consumed by another team.
Image Credit: Pictofigo
Ever asked yourself how you could be successful with Agile at scale? Let me show you how we’ve done it at LeadingAgile.
In this one hour session that I presented to the PM Symposium in Washington DC, I explained how we’ve been successful by focusing on culture last and predictability first.
Though I’ve been doing Enterprise Agile Coaching with LeadingAgile for over a year now, I haven’t been doing a lot of training (or blogging). I’ve been sticking to agile transformation work and the occasional private class.
Well, it’s time for an update. Dennis Stevens and myself co-authored the International Consortium for Agile (ICAgile) Agile Project Manager learning objectives back in February. The result was a solid certification even a PMP could respect.
New Classes and Locations
LeadingAgile has decided to offer more public training. We’re offering classes in Atlanta, Denver, Orlando, and Washington DC.
Certified ScrumMaster certification class
Certified Scrum Product Owner certification class
PMI Agile Certified Practitioner (PMI-ACP) certification prep class
Fundamentals of Agile (CIP certification awarded)
Agile Project Management (to be announced)