Defined vs Specified, Planned

[Emiliano Heyns]

Hi guys,

What is the difference between the Defined and Specified story states?
And what is the intended meaning of the Planned field?

Thanks,
Emiliano

[Christopher Johnson]

Hey Emiliano,

Defined is basically "the user story has been created, though it may not be complete"
Specified is "the user story is defined and ready for development" (usually means it has acceptance tests)

The Planned field is for the story point estimates (integers).

-c

--
Cofounder and CEO
ifPeople - Innovation for People
t: 678-608-3408 x16
www.ifpeople.net
blog.ifpeople.net

[Christopher Johnson]

Emiliano,

On a similar note...can you explain why in the backlog, user stories have 2 states? ie defined/defined, defined/in-progress, etc

Thanks,
Chris

[Emiliano Heyns]

Ok, so defined stories are not likely candidates for a sprint. The
Planned field has an unfortunate overlap with the Size field. I'll see
what I can do about mending that. I'd love to keep an option to
restrict story points; free choice adds unwanted detail-level
discussion at our place ("should this be 101 or 102?").

On Aug 11, 9:42 pm, Christopher Johnson <c...@ifpeople.net> wrote:
> Emiliano,
>
> On a similar note...can you explain why in the backlog, user stories have 2
> states? ie defined/defined, defined/in-progress,
>

I have changed this behaviour in svn, but the first state was the
state as recorded in the story, and the second was calculated bases on
its "behaviour"; is it included in a sprint, was it part of a sprint
that has ended but wasn't marked with an end-state like failed or
accepted, etc.

[Emiliano Heyns]

On Aug 11, 10:14 pm, Emiliano Heyns <Emiliano.He...@gmail.com> wrote:

> I have changed this behaviour in svn, but the first state was the
> state as recorded in the story, and the second was calculated bases on
> its "behaviour"; is it included in a sprint, was it part of a sprint
> that has ended but wasn't marked with an end-state like failed or
> accepted, etc.

Specifically:

* If a story is archived, show it as archived
* If a story is "defined", show it as "needs work"
* if a story is not assigned to an iteration, is is "unplanned"
* if a story has an end-state (failed or accepted), show that
* if the story is assigned to a sprint in the future, it is "planned"
* if the story belongs to a print that has ended, but it has no end-
state, it is "forgotten"
* if the story is part of an onging sprint, it is "in progress"

else it is "unknown" (but this should never happen)

[Christopher Johnson]

Thanks for the clarification, Emiliano.

Can you also explain the copy/move/archive process?

As I understand it, if you move and copy a user story to an iteration, there is a separate copy in the backlog, so when you interact with the one in the iteration, it doesn't get reflected on the backlog. Something like that? Maybe not? :D

We haven't used the archive part yet, mostly from not know what it does...

-c

[Emiliano Heyns]

On Aug 11, 11:19 pm, Christopher Johnson <c...@ifpeople.net> wrote:
> Thanks for the clarification, Emiliano.
>
> Can you also explain the copy/move/archive process?
>
> As I understand it, if you move and copy a user story to an iteration, there
> is a separate copy in the backlog, so when you interact with the one in the
> iteration, it doesn't get reflected on the backlog. Something like that?
> Maybe not? :D
>

move is just iteration reassignment as it always was. Copy does indeed
create a fresh, unrelated copy of the userstory, so the iteration
history doesn't get altered by accident. Move is disabled if tasklogs
have been created against the story (indicating actual work has been
done on the story). Delete vs archive works the same way.

> We haven't used the archive part yet, mostly from not know what it does...
>
> -c
>