How to handle unfinished tasks in an iteration

[grayaii]

I have a process question.
What happens if you're half way through your iteration and you realize
an "In Progress" User Story will not be completed in this iteration?

Currently we Split the story (either into the next iteration or the
backlog) and leave the "In Progress" story as "In Progress" *and*
"Closed". Is it correct to leave that story as "In Progress" *and*
"Closed"?

We do this so that we can go back to past iterations and see stories
that were split.

Note: We also have a process where if you don't even start a User
Story in your iteration and you realize you won't even start it, we
split it, but change the status to "Future" (opposed to In Progress,
since we never even started it.)

What's the correct process for unfinished User Stories in an
iteration?

-alex-

[Andre Nelson]

This is a question for which I can see you getting multiple answers.  I'll give you how we do it at my company (which is a fetus in terms of its Agile implementation).

BLI that are not started just get moved either to the Backlog or to the next sprint.  There is no use splitting them as there was no value even remotely added by that BLI so it shouldn't be tracked as part of that sprint.

BLI that are partially done.  This is a two parter.

1. For items where some amount of tasks were done, but the item cannot be considered complete, we split it and leave it as In Progress and Closed
   
2. For items where some amount of tasks were done and this can be considered done/tested, this BLI is marked as Done/Accepted. (For instance, doing an add feature - the button was completed, the tables are done, but I didn't finish the code.  So, this BLI can be renamed "Add Feature DB and button" and it can be marked as done/accepted.  In this case, the new BLI after the split contains the work to implement the back end code and I could rename the BLI as such)

Again, this is just how we are doing it, but it works for us so far.  Let me know if that didn't make any sense.  :-)

- Andre L. N.

[grayaii]

Hi Andre,

Thanks for the reply.
One value of splitting BLI's that are not started is to keep a "cookie
crumble" in that iteration.
It allows us to ask the question during our end-of-iteration
retrospective: "We originally planned to do this task, but for some
reason we didn't even start it. We should keep this in mind so that
we plan better for the next iteration. How can we plan better to avoid
this?"
If we just moved it, we probably would forget that we moved it. I
wonder if what we are doing is indeed correct.

Have you found any documents that talk about how to handle this? I'm
very curious.

-alex-

On Mar 30, 1:12 pm, Andre Nelson <nel...@fstrf.org> wrote:
> This is a question for which I can see you getting multiple answers.  
> I'll give you how we do it at my company (which is a fetus in terms of
> its Agile implementation).
>
> BLI that are not started just get moved either to the Backlog or to the
> next sprint.  There is no use splitting them as there was no value even
> remotely added by that BLI so it shouldn't be tracked as part of that
> sprint.
>
> BLI that are partially done.  This is a two parter.
>

>    1. For items where some amount of tasks were done, but the item

>       cannot be considered complete, we split it and leave it as In
>       Progress and Closed

>    2. For items where some amount of tasks were done and this can be

[Andre Nelson]

Hey,
One thing to note about what you said is that in V1 there is a scope change report.  This will tell you what things were added, removed, or changed during a given sprint.  So, you actually don't need to do that extra bit of leg work if you didn't want to.

-Andre L. N.

[Alexander Gray II]

Hi Andre,

Cool!  We were unaware of that report!
Thanks!
-alex-

[Kevin S.]

Grayii-

This has been debated many times... I just skimmed the search results
for the word split and came up with these items:

http://groups.google.com/group/versionone-users/browse_thread/thread/528ff7b124fa79f4/492c3e5293408617
http://groups.google.com/group/versionone-users/browse_thread/thread/4a8689063dd01b3c/f7726583fedebfde
http://groups.google.com/group/versionone-users/browse_thread/thread/8acf92fe24fd28b9/ba6739a929bca82d
http://groups.google.com/group/versionone-users/browse_thread/thread/dfccf9e89d4adf99/eccc146d4b04fd69
http://groups.google.com/group/versionone-users/browse_thread/thread/13eaf3f773af5cc8/ee0cdd3f91139e93
http://groups.google.com/group/versionone-users/browse_thread/thread/598ffe12b9ec380e/a7883020f0f0ba1d
http://groups.google.com/group/versionone-users/browse_thread/thread/a76b4f4877cb8bf9/1353c7d0c12a8170

For a more philosophical view, check out this blog post-
http://agile-commentary.blogspot.com/2008/06/splitting-story.html
http://agile-commentary.blogspot.com/2008/11/what-is-done.html

For items where you know you won't start the story during the current
sprint, I would advise having a process (scrum master, team, or
product owner) to "push" that story forward to the sprint you do
expect it to happen in. If you use a more mature pull process, then
it would simply go back on the product backlog (no sprint
assignment). The process I speak of is really to insure there is a
communication between the team and the customer/PO to insure that the
change in commitment (from sprint planning) has been communicated.

[grayaii]

I read most of those posts before I posted, but I couldn't quite get a
solid "recommended" process and having the tool 'be happy' with it.
(Just thinking about loud, will User Story Dependencies be OK, if a
split story is left as "In Progress"? I'll go check...)
But it seems from your comment that as long as we have a process and
stick to it both Andre and I will be satisfied.
that works for me!
Thanks Kevin!

On Mar 30, 1:35 pm, "Kevin S." <ksch...@gmail.com> wrote:
> Grayii-
>
> This has been debated many times... I just skimmed the search results
> for the word split and came up with these items:
>

> http://groups.google.com/group/versionone-users/browse_thread/thread/...http://groups.google.com/group/versionone-users/browse_thread/thread/...http://groups.google.com/group/versionone-users/browse_thread/thread/...http://groups.google.com/group/versionone-users/browse_thread/thread/...http://groups.google.com/group/versionone-users/browse_thread/thread/...http://groups.google.com/group/versionone-users/browse_thread/thread/...http://groups.google.com/group/versionone-users/browse_thread/thread/...
>
> For a more philosophical view, check out this blog post-http://agile-commentary.blogspot.com/2008/06/splitting-story.htmlhttp://agile-commentary.blogspot.com/2008/11/what-is-done.html

[Kevin S.]

I agree with your statement that any process followed by all is good,
with the caveat that your team must be willing to constantly improve
the process based on retrospectives on a regular basis (no less often
than once per month). This is the Alistair Cockburn approach to Agile
(as opposed to the Scrum or XP by the book approach).

That being said, many people in the industry can help provide advice
since they've been there before... but unfortunately many of us can
only provide "armchair advice" unless we have a real good conversation
about your culture and environment also.

Good luck.

On Mar 30, 1:51 pm, grayaii <gray...@gmail.com> wrote:
> I read most of those posts before I posted, but I couldn't quite get a
> solid "recommended" process and having the tool 'be happy' with it.
> (Just thinking about loud, will User Story Dependencies be OK, if a
> split story is left as "In Progress"?  I'll go check...)
> But it seems from your comment that as long as we have a process and
> stick to it both Andre and I will be satisfied.
> that works for me!
> Thanks Kevin!
>
> On Mar 30, 1:35 pm, "Kevin S." <ksch...@gmail.com> wrote:
>
> > Grayii-
>
> > This has been debated many times... I just skimmed the search results
> > for the word split and came up with these items:
>

> >http://groups.google.com/group/versionone-users/browse_thread/thread/......
>
> > For a more philosophical view, check out this blog post-http://agile-commentary.blogspot.com/2008/06/splitting-story.htmlhttp...