As more of our customers are transitioning to agile and we work on more agile projects, we’ve identified a set of common issues that can hinder a team’s ability to deliver value with the agile cadence. These issues are focused on agile delivery and less on issues with agile transformation in an organization (like middle management not bought in). We are curious to hear if you have seen similar issues on your own teams, or if there are others we didn’t mention here, so please feel free to comment with your own experiences and suggestions!

Product Owners aren’t trained to be Product Owners
A weak Product Owner can negatively affect the whole scrum team. When the role is new and Product Owners don’t understand the proper agile delivery cadence, it’s difficult to be an effective Product Owner.

Product Owners aren’t empowered to make quick decisions on behalf of the business
When Product Owners aren’t truly empowered to make snap decisions, they end up going back to the business to get open questions resolved. Business stakeholders aren’t always readily available, which causes delays in delivery.

Business stakeholders still expect to get everything they ask for within a strict budget and timeline
When stakeholders still expect to get everything, development teams can suffer from “death march” mandates to finish everything in the backlog during the last sprint.

Requirements aren’t traced to business objectives
When stories aren’t traced back to objectives, it’s much more difficult to prioritize stories as they’re added to the backlog and to rationalize about cutting scope when necessary.

Organizational SDLC mandates still require comprehensive documentation
Requiring teams to produce BRDs for agile projects, then requiring CRs when things change after documents are approved, prevents teams from embracing change and valuing working software over documentation.

Requirements are not groomed before the start of a sprint
If requirements are not complete and haven’t been reviewed with the development team prior to the start of the sprint, the delivery cadence is compromised for the sprint. Developers have to wait to get complete requirements sets and have to inefficiently task switch when open issues are waiting to be resolved with business stakeholders.

Requirements change significantly mid-sprint
The development team should own the sprint backlog. Ideally your sprint stories are well-groomed and complete upon entering the sprint. When there are a lot of open items in flux and stories change significantly, it compromises the development team’s ability to meet the commitments they made at the start of the sprint.

Teams don’t allow for sprint 0 activities, so Product Owners can never get ahead
Product Owners should have 1.5-2 sprint backlogs groomed and ready to go before development starts. When developers come on board without allowing time for sprint 0 activities to get ahead with grooming, and they want to start coding right away, the Product Owner is constantly behind from the very start.

Requirements aren’t “done, done, done” by sprint review
If some development is left towards the end and doesn’t get completed, or leave enough time for QA, stories spill over into the next sprint.

Product Owners don’t have enough time
If the delivery cadence is thrown off from the beginning, POs are constantly playing catch up and don’t have adequate time to devote to the demanding tasks of being constantly available to answer questions for developers mid-sprint, while also grooming user stories in the backlog for future sprints.

Product Owners don’t use visual models to inform the requirements
Visual models are still essential in developing a common definition of done and mental model of the solution. Developers have a better understanding of the requirements (and there are less defects) when Product Owners provide visual models instead of relying solely on user stories and acceptance criteria to convey requirements.

Product Owners don’t break down user stories into digestible chunks
Requirements should follow INVEST guidelines (independent, negotiable, valuable, estimable, small, testable); if stories are too big, they’re harder to estimate, more at risk for not getting done during the sprint, and more difficult to test.

Development teams aren’t diligent about adding tasks to user stories
Development teams that are new to agile, and particularly teams that are not co-located, may not understand the value of planning out all tasks for each user story during sprint planning. Then, the ability to be introspective about their work is compromised, since they can’t track velocity, and Product Owners don’t have visibility into task completion rates so they can begin assessing the “doneness” of stories.

Development teams aren’t using continuous integration
Teams that don’t use continuous integration best practices can code over one another and waste time in the development process.