Skip to main content

Marking Not Done vs Removed

Last post 07:22 am December 3, 2013 by Ian Mitchell
3 replies
05:19 am December 3, 2013

Hello

Our team committed a PBI and during the initial days of sprint we found out that because of the external dependency we can not complete the committed PBI. So what should be our action plan now -

1. Shall we mark the PBI as Not Done or just remove it from sprint backlog?

2. Team is ready to take next priority work of the same story point, is it allowed during the sprint?

Cheers
Sanjay


05:36 am December 3, 2013

Hi Sanjay,

Allow me to share some of my thoughts....

1. I would ask whether there is any value in making this item visible for all? It may be a discussion point at the Retrospective or who knows, the dependency May be fulfilled within the existing Sprint cycle? Ultimately, check with what the Scrum Team thinks?

2. Yes -- if the Dev Team has the ability to take on more, given the circumstances, they should pull the next order of item from the product backlog that is ready. This will also be discussed at he Daily Scrum but I would also bring awareness to the PO.

The PO should be made aware of these as he/she also has to see the potential impact ahead.


05:41 am December 3, 2013

One additional thing --
The SM may want to check with the team whether it makes sense to have an "On Hold" status.

There may or may not be value in this for the team.


07:22 am December 3, 2013

> ...we can not complete the committed PBI. So what should be our action plan now...

Figure out what you need to do so you can still meet the Sprint Goal. Was this PBI essential to the goal, or can you find a workaround that will allow you to deliver the increment?

If there is a workaround, inform the Product Owner of the issue and the solution you propose which should still allow the Sprint Goal to be met.

On the other hand, if the PBI is essential to the Sprint Goal, the Product Owner should be notified and told that the increment is at risk because of the external dependency. The PO and Scrum Master can then work together to overcome that blockage. Failing that, the PO can work with the Development Team to revise the Sprint Backlog in order to meet an alternative goal of suitable value.

In either case, it will be essential to address this problem in the next Retrospective. This is because the Development Team clearly do not own their process and are unable to take each item on their Sprint Backlog through to completion. The required technologies and skills should either be brought in-house (i.e. into the team) or PBI's with such dependencies should not be accepted by the team in the first place.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.