Agile Development & Unfinished Stories

What do we do about User Stories which are almost done on Sprint Completion? — A question which we have heard on many occassions and is inevitable at some point

Should we quantify this specific NOT DONE story points?

Let’s walk thourgh the following:

1. How to handle unfinished Stories in a Sprint ?
2. Should we quantify these NOT DONE story points ?
3. Need of a new metric - velocityX
4. Summary

1. How to handle unfinished Stories in a Sprint ?

The Sprint is a time boxed event and the outcome of this iteration is a potentially releasable product. That in pricipal means that the Story can only be in one of the binary states i.e. “DONE” or “NOT DONE”. This is also what will give real value for the intended stake holders.

When we reach the end of the Sprint, there can be the following scenarios based on the status of development of the Story:

1. Only Peer Review remains
2. User Acceptance Tests remains
3. Development not complete

If the team is proactive, then the first 2 scenrios can be takled early and the team can self manage coming together to complete and move the potentially spillover story to “DONE” in due time. On the other hand, if there are many such stories then with the help of the Product Owner the team should prioritize and finish the most important one and then move on to the lesser important ones. This also calls for retrospective and adapting to improve future planning.

Anyway the third point where the development is no completed, is the interesting one. What do we do then? In my opinion, since this is the binary “NOT DONE”, following steps need to be taken:

1. Before the end of Sprint, an attention is raised on stories the team might not be able to finish. This gives an opportunity to act as a team to finish the due work. The product owner gets a chance to communicate to the stakeholders accordingly.
2. At or before the Review Meet, the team documents the remaining work on the User Story and estimates it latest by the next Planning meet.
3. The “NOT DONE” stories are moved to the Product backlog. The Sprint is closed here. The Scrum Team only got velocity points for completed tasks. The product owner can re-prioritize them based on the remaining story points and the market needs
4. The “NOT DONE” stories are taken to the Sprint Retrospecive to discuss as part of people and processes to see how we can adapt and improve further to bring the “NOT DONE” stories to a minimum

2. Should we quantify these NOT DONE story points ?

Let’s look at what are the possibilities here:

The User Story is marked as “NOT DONE” and moved to the next Sprint or some other sprint based on the priority set by the product owner. All Story points are credited to the future sprint where the story will be marked as “DONE”.

For example let’s consider a simple case where the User Stroy was estmiated as 8 story points, and after the Sprint X completion the remaining was estimated as 3 story points.

For predictability, let’s say the average predictable velocity for the team is 24.

Sprint X

Predicted & Planned = 24 SPs

Velocity = 16 SPs (24 - 8, due to moving of whole US to “NOT DONE”)

Unaccounted Work = -5 SPs (8-3, due to the 3 SPs as remaining estimate)

Sprint X + 1(n)

Predicted & Planned = 24 SPs (includes remaining 3 SPs)

Velocity = 29 SPs (24+5, due to moving of whole US to “DONE”) OR 24 SPs

Unaccounted Work = +5 SPs (5 SPs of work done from Sprint X) OR 0 SPs

Now, let’s say that the team was coached well and during planning or before for the Sprint X + 1, and re-estimate the story to 3 SPs. Hence the unaccounted work for Sprint x +1 is 0 SPs. However the unaccounted work for the Sprint X being 5 SPs still holds true.

This -5 SP which is unaccounted for, makes the slight difference not only for measuring and improving predictability, but also for the team to know about their efforts and the journey to improving it.

Predictability ratio options (planned to done):

Sprint X: 16/24 = 0.55, If 5 SPs of unaccounted work is factored: 21/24 = 0.87

Sprint X +1: 29/24 = 1.20 OR 24/24 = 1

Having a false 1.20 score continously is not good either as that means not optimal planning or the team is not challenged enough. For Sprint X you see a difference of 0.55 vs 0.87 depednding on if you factor the unaccounted work. And these sizes can differ over different sprints which also means the “Value” predictability graph migh not be consistent with the “Work done” predictability graph. Capacity and team mindset is an importnat coefficiant in achiving great development and release cycles.

3. Need of a new metic - velocityX

In order to address the above problem, I thought of calling this variable for quantifying the lost velocity value as velocityX. You may call it whatever you like and it may have synonyms which I am unaware of. However the naming is important because without the name we have all come across this issue but never managed to tackel it in a standard way.

So what is this velocityX? In simple terms it is the amount of story points which are delivered by the team in a sprint but are not accounted for because of being part of unfinished stories, consequently not delivering value to the customer. In the example above it is 5 SPs.

4. Summary

The question we need to ask in my opinion is, In order to deliver the 8 SP value to the customer, How much should the team work done improve?

So inorder to impove the predicatbility from 0.55 to 1, how much should the work done improve? i.e. it should be 0.87 to 1.

This metric is seldom seemed as important or maybe “needed” for a start, however in my opinion for high delivering teams, this is a metric which will further help measure and improve the predictability by accounting for the “How much to improve to deliver the required value predicatbility”. Even for beginner teams this can be a big help.

I call this unaccounted velocity from Sprint X as velocityX, which can be tracked thorough the iterations and minimized to achieve better results.

We do understand that all this is just not for some management reports, but rather to achieve better team results by predicting better and adapting faster. The other consequence is that the team feels that the work they have done is not Lost in some reports :)