Can a functional story be considered complete if either QA or Doc work is not complete?

Kim,

Why would you lose the history of the work completed if the story carried over to the next sprint?

The sprint should produce functionality that may be released to production. Can the functionality be released without the end-user documentation?

Look to your Definition of Done to determine whether a story is complete or not. If at the end of the sprint it does not meet DoD, it simply is not complete. Since nothing has been "delivered", you cannot get credit for finishing most of it. Either it carries over to the next sprint (in its entirety), or it is de-prioritized and moved back to the backlog (Product Owner discretion).

What I would strongly advise against is splitting up the story by task in order to close the "completed" portion of the story, and carry over the remaining work. That is simply a wasteful practice.

In your retrospective, look at why the documentation task wasn't finished. Was there anything in hindsight that could have been done to help finish it within the sprint?

Good luck.

Thanks for the quick response Tim. When I mentioned about losing the history of the work I guess I should have said getting credit for the work in the sprint. If it is a story that dev took a week of work to complete and qa also a day or so and the only thing not done is the story and I move it to the next sprint will it seem the dev team was under utilized or did not produce much for the original sprint. Because the story associated with a week of work was moved.

But I do take your point on the DoD. That is something I think as an organization we have not given the right attention to defining clearly.

> ...I guess I should have said getting credit for the work in the sprint

There is no credit for undone work in Scrum, as the only measure of progress is the actual delivery of valuable working product.

Undone work should be re-estimated on the Product Backlog to show the work that is believed to remain. The amount of work that is left to be done may be reduced due to effort expended. However, this reduction in scope cannot be credited as an *empirical* measure of progress where the corresponding product value is not delivered.

Hello Tim ,

Any undone or left over work will not be given any credit. It needs to be re estimated with the left over work to be delivered.
Effort may be reduced. It can be a spilled over to next sprint.

Thanks

Re-estimation of incomplete stories is a wasteful practice. I would offer this as an opinion, but it is very much true.

What value is being provided by the team in evaluating an 8-point unfinished story (for example), and determining how much of the relative estimate remains? Would it not be easier to just keep the story intact as 8 points, instead of having the team engage in this practice? How much time is wasted if there is not immediate consensus within the team around the size of the effort remaining?

I feel re-estimation also distorts a team's velocity. Again for example, an unfinished 8-point story is re-estimated at 3 story points (remainder of undone work).

Should the 5 story points completed in the sprint simply "disappear" because the story was not delivered? No.

Should the 5 story points be credited to the team for that sprint? No.

Allowing the 8-point unfinished story to remain intact (and possibly carried over to the next sprint) reinforces the principle of Working Software as the primary measure of progress, and the discipline around meeting the Definition of Done.

Re-estimation in my mind is simply a wasteful carryover from traditional project management methodologies and related tracking practices (What % of the story is finished, and what % remains?)

Posted By Kim Tyler on 03 Jun 2016 05:03 PM
Thanks for the quick response Tim. When I mentioned about losing the history of the work I guess I should have said getting credit for the work in the sprint. If it is a story that dev took a week of work to complete and qa also a day or so and the only thing not done is the story and I move it to the next sprint will it seem the dev team was under utilized or did not produce much for the original sprint. Because the story associated with a week of work was moved.

Kim,

As Ian mentioned, credit should only be given for completed items that meet the Definition of Done. And it is a team effort, not just Dev, or QA, or Technical Writers. A frequent struggle with early Scrum adoptions is the concept of joint ownership of stories. Teams need to resist the tendency to throw work over the wall to other specialists, or point fingers when parts of a DoD are not finished in a sprint.

Keep in mind, Scrum is not about being perfect. In fact, there is an old adage in Agile that states "Failure is not an option, it is mandatory."

When a story is undone in a sprint, it is critical for the team to discuss the possible reasons why, and come up with ways to try to mitigate it from happening in the future. Agile is about continuous improvement, not marching to a perfect drumbeat and then beating yourself up when you fail to keep time.

What is interesting is that traditional project management methods were very good at providing the illusion of perfect progress without actually making it. It is why most waterfall projects are green 2/3 of the way before they suddenly turn red and dates are pushed/compromised.

Thanks everyone for the feedback. This has been very helpful. Obviously we are just getting our feet wet and glad I found this resource for searching for answers and asking questions!

I would avoid using the word "credit" when referring to points. It's not a reward system, Points are only used for a few purposes. They are used to relatively size stories. The are used by the team to forecast how many stories they may accept into a sprint. They are used to calculate team velocity for the team. The PO may use them to help determine priority and in release planning. You cannot compare points between teams. Velocity is not the only measure of goodness for a sprint or team. Points are simply an estimation tool. There should not be a bad connotation to not getting a story done, there is an assumption of innocence and when a story is not completed there is should be knowledge gained through the process.

The refinement process is correlated to the maturity of a PBI (may be a User Story).
The first time you'll present the story to your Development Team, they will forecast the story points, based of what they have understood and by comparing the work to do with other stories.

If the PBI is not clear, your cone of uncertainty will be greater, the estimation of the Development Team may be less accurate. Moreover, during the Sprint more work can emerge into the sprint backlog.
Don't forget that the Development Team try to forecast their work, how would you want to have a clear sprint goal if there is too much incertitude in your PBI.

Does the velocity will help the Scrum Team to create a Product if there is too much uncertainty?
Does the Product Owner will be able to have actionable feedback if all the work can't be shown to the Stakeholders?
How will react your stakeholders during the next Sprint Review if they can't understand on what you've work?

The purpose of a sprint is to deliver a peace of functionality, it is not mandatory to be a big chunk of your product. You just have to walk step by step.