Skip to main content

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

Last post 05:45 am June 11, 2016 by Benjamin D’Eusanio
9 replies
03:01 pm June 3, 2016

Hi. My company is newly adopting Agile methodology and one question we are stumbling over early on is the way to handle sprint stories in terms of completion of associated qa and / or end user doc requirements.

When creating our stories we are entering QA and documentation tasks as subtasks to the story.

But sometimes we find that, probably due to the fact we are still refining the Agile process, the development work on the story may be done, and even the QA. But the doc sub task is not complete.

Technically should the story be moved to the next sprint because of that? But then we would lose the history of the work completed in the sprint which could have been considerable.

Or do we remove that subtask for the doc and create it as a task for the next sprint and close the story in its original sprint?

Appreciate any suggestions. Thanks


04:57 pm June 3, 2016

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.


05:03 pm June 3, 2016

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.


01:11 am June 4, 2016

> ...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.


03:11 am June 6, 2016

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


09:48 am June 6, 2016

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?)


10:28 am June 6, 2016


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.


06:27 pm June 6, 2016

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!


11:37 am June 10, 2016

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.


05:45 am June 11, 2016

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.


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.