Managing Unfinished Work in Scrum

In ideal situation all the User Stories should be completed by the end of the Sprint. But in reality because of multiple reasons we have some unfinished User Stories at the end of Sprint. Some teams move those unfinished User Stories to next Sprint. But the problem of this method is that we are actually changing the Scope of current Sprint while executing the Sprint and it is against the principle of Sprint. Sprint recommends that once you start the Sprint, the Scope of the Sprint should never change. 

The other effect of moving the unfinished User Stories to next Sprint is on Burn Down Chart. As you move unfinished User Stories to next Sprint, Burn Down Chart will dramatically come down to zero. This Burn Down Chart will give false impression that the Team has Burned Down all the User Stories of current Sprint. 

Please refer the Burn Down Chart below. It gives an impression that all the User Stories for a given Sprint were Burned Down. 

If you see the Burn Up Chart of the same Sprint then you will see that the Scope of the Sprint is changed almost every day and at the end of the Sprint the Scope has reduced steeply. Ideally the Scope line of Burn Up chart should be straight line. 

It is expected that in a Retrospective session, Team will discuss the reasons behind Unfinished User Stories and take corrective actions to avoid it in future. But if a Team refers above Burn Down Chart then there won't be any unfinished work and Team will miss an opportunity to learn and improve for next Sprint. 

Instead of moving unfinished User Story to next Sprint, Team should Split unfinished User Story. By Splitting the User Story, we will keep the original User Story into current Sprint and move the unfinished part of User Story to next Sprint.By this method your Burn Down will have still some ToDo tasks at the end of Sprint for unfinished User Stories. But this is okay. Team can use that data for the Retrospective session. 

Rally software provides nice feature of Splitting User Story. You can refer a URL below for the video of Splitting User Story in Rally.

https://help.rallydev.com/manage-unfinished-work

Guidelines for Effective Backlog Grooming Session

1. Schedule Backlog Grooming session at the middle or second half of the Sprint
2. Product Owner will present the User Story to the team.
3. If team has queries about the User Stories then they can ask clarifications to the Product Owner
4. Team will review the estimates and if needed re-estimate the User Stories
5. Team will confirm that each User Story has an Acceptance Criteria
6. Team will review that User Story don't have dependency on other User Stories
7. User Stories enough for next 2 Sprints will be groomed in this session
8. It is recommended that Development Team review the Product Backlog Items 24 hours prior to Backlog Grooming meeting.

ScrumBut

Many organizations try to implement Scrum but unless they adopt Scrum completely they don't achieve the success what they are expecting by implementing Scrum. Many times ScrumButs are the reasons why teams can't take the full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum.  

In Scrum every Role, Event or a Timebox is designed to provide the desired benefits and address predictable problems. Sometimes organization implement Scrum but with certain modifications to Scrum Roles, Events or Timeboxes; because of some organizational challenges. In this scenario, organizations are implementing Scrum but with modifications to some of the aspects of Scrum and it is called ScrumBut. 

ScrumBut has a syntax (ScrumBut)(Reason)(Workaround)

Examples

1.  (We are following Scrum but )(sometimes we get ad-hoc requirements,)( so we update the Sprint Backlog in the middle of Sprint and don't achieve the goal of the Sprint)
2. (We are following Scrum but)( some team members are at different location, )(so they don't attend the Daily Scrum Meeting)
3. (We are following Scrum but)( we think Backlog Grooming Session is a waste of time, )(so we don't do Backlog Grooming Sessions)
4. (We are following Scrum but )( team members are very busy in doing assigned tasks, )( so they don't update hours remaining on daily basis)

As mentioned above, each of the Scrum Roles or Events has certain purpose and if you tweak it for your project situation then you won't get full benefits of Scrum. So it is recommended to implement Scrum by avoiding any of the ScrumButs.

Definition of Done Vs an Acceptance Criteria

Since long there was a confusion in my mind regarding Definition of Done and the Acceptance Criteria. I was thinking that Definition of Done is same as an Acceptance Criteria. But recently I was going through some videos on Scrum and in one of the videos this difference is explained beautifully.

Last week I started working with a project practicing Scrum since couple of years and I asked the team if they know the difference between these two terms. I found out that they were also thinking that both these terms have same meaning.

So what is DoD and how it is different from an Acceptance Criteria? Definition of Done is a list of requirements that a user story must adhere to for the team to call it complete. While the Acceptance Criteria of a User Story consist of set of Test Scenarios that are to be met to confirm that the software is working as expected. The difference between these two is that the DoD is common for all the User Stories whereas the Acceptance Criteria is applicable to specific User Story. Acceptance Criteria of each User Story will be different based on the requirements of that User Story. In order to complete the User Story; both DoD and Acceptance Criteria must be met. Unless both these two lists are done the Product Increment is not complete.

Before the start of the Sprint the Product Owner and the Team should agree on Definition of Done. DoD should not be changed during the Sprint. If changes need to be done then it should be done between Sprints.

To understand these terms better let's see the examples of Definition of Done and the Acceptance Criteria

Definition of Done

• Code Builds without error warning 
• Code is Unit Tested
• Code is Deployed to system test environment and passed system tests
• Build pushed to demo server 
• Remaining hours of the User Story are marked zero

Acceptance Criteria

•  A user cannot submit a form without completing all the mandatory fields
• Information from the form is stored in the registrations database
• Payment can be made via credit card
• An acknowledgment email is sent to the user after submitting the form

I would suggest that each user story should have both the DoD and AC as a check box list and the developer should check all the check boxes for both the lists before that user story is marked as complete.