Challenges in Scrum IT Projects

1. Adhoc request in the middle of the sprint from PO

Why is this occurring?   Does the PO understand that the team's ability to meet their forecast is impacted by such behavior?   Why isn't the Scrum Master actively protecting the Development Team from such interference?

2. Requirement changes in mid of Sprints

See response to #1.   In addition, what has been the discussion in the Sprint Retrospectives regarding this?   Why are items still unclear even after they have been offered and accepted into a sprint?

3. Re prioritization of user stories when sprint is on

The Development Team MUST be in charge of their Sprint Backlog, including how items are completed, and in which order.   Per the Scrum Guide: "Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team."

4. Last minute withdrawal of requirement

See response to #2.

5. Back out entire user stories post deployment

Assuming that the items have been delivered, accepted by the PO, and meet the Definition of Done (DoD), it is certainly at the discretion of the PO whether to release the item(s).   However, since the item has been completed according to the terms of Scrum, it is unwise to "back out" those items after they have been deployed.   

If there are inaccuracies or errors discovered post-deployment, the PO should be creating new items to address that, and leaving the original item closed (in my opinion).

6. Missing clarification on requirements duringTh the start of the sprint

A good discussion topic for your next Sprint Retrospective.   Several of your concerns seem to center on poor item refinement and a lack of item readiness.   Many teams utilize a Definition of Ready (similar to a DoD), and while this does serve as sort of a toll gate within the Scrum process, having criteria that an item must meet before it can be offered to the team may help mitigate some of your refinement and interference issues.

Good luck!

In Scrum, the Development Team should wholly own their Sprint Backlog and technical practices. What are the Development Team currently doing in response to the challenges you describe?

How has the Scrum Master set about coaching the PO and others in the best use of Scrum?

Hi Timothy,

Thanks for your input. However for point #1 and #2. I think in real time scenario such instance do occur. So is it right process to tell business to take out some user stories from current sprint to accommodate the new adhoc requests.

Thanks!

Jyoti

In addition to all of the other great answers given: do your Sprints have a Sprint Goal?  The Sprint Goal can provide your Development Team with the gift of focus, and be their North star.  Take note to what the (now optional) Daily Scrum questions all end in.  The Development Team should be laser focused on the Sprint Goal, and replan their work on a daily basis with the Sprint Goal in mind.

When that ad-hoc request comes in from the Product Owner, the Development Team can discuss with him/her how the Sprint Goal may be impacted.  If the ad-hoc request is more important than the Sprint Goal, perhaps the Product Owner may have to make a tough decision to cancel the Sprint.  When faced with that decision to cancel, most likely the ad-hoc request can wait until next Sprint.