Agile process-relationship between story, story point, tasks
Hi,
Which is the relationship that I should implement to follow an agile
development using the agile process template that comes out-of-the-box
with RTC?
I want to get the following scenario:
* The user introduces a story in RTC and evaluates the story points
* The story should be implemented in different tasks each one with its
time estimation. So, should I create child tasks for the user story?
What would be the relationship between story points and tasks?
Any documentation you may provide to me regarding how the agile process
template that comes out-of-the-box with RTC would be great.
Many thanks in advance,
Ana
Which is the relationship that I should implement to follow an agile
development using the agile process template that comes out-of-the-box
with RTC?
I want to get the following scenario:
* The user introduces a story in RTC and evaluates the story points
* The story should be implemented in different tasks each one with its
time estimation. So, should I create child tasks for the user story?
What would be the relationship between story points and tasks?
Any documentation you may provide to me regarding how the agile process
template that comes out-of-the-box with RTC would be great.
Many thanks in advance,
Ana
One answer
Ana Lopez wrote:
You are on the right path. It's common to define a story to describe
work on a high level and then break it up into several implementation
tasks. Usually this is a two level process (including estimation)
(1) Define all stories that you have or that your customer wants to get
implemented. Prioritize the stories and estimate them using story points
or any other abstract notion. Taking an abstract notion makes them
comparable with each other, but doesn't bring any expectations into the
game. (If you would use hours, your customer might assume that you are
done at a on date X, but actually at this stage the work definition is
way fuzzy as it would allow for accurate estimates).
(2) In a second step, you or your developers can break down stories into
several implementation task. They shouldn't be longer than a day. By
doing so, you have small and compact work packages that are easier to
estimate and to track progress on.
Of course, the number of implementing task and their sum of (realtime)
estimates does (or should) correlate with story points. Over time you'll
learn how many story points you are able to get done during an iteration.
--
Cheers, Johannes
Agile Planning Team
Hi,
Which is the relationship that I should implement to follow an agile
development using the agile process template that comes out-of-the-box
with RTC?
I want to get the following scenario:
* The user introduces a story in RTC and evaluates the story points
* The story should be implemented in different tasks each one with
its time estimation. So, should I create child tasks for the user story?
What would be the relationship between story points and tasks?
You are on the right path. It's common to define a story to describe
work on a high level and then break it up into several implementation
tasks. Usually this is a two level process (including estimation)
(1) Define all stories that you have or that your customer wants to get
implemented. Prioritize the stories and estimate them using story points
or any other abstract notion. Taking an abstract notion makes them
comparable with each other, but doesn't bring any expectations into the
game. (If you would use hours, your customer might assume that you are
done at a on date X, but actually at this stage the work definition is
way fuzzy as it would allow for accurate estimates).
(2) In a second step, you or your developers can break down stories into
several implementation task. They shouldn't be longer than a day. By
doing so, you have small and compact work packages that are easier to
estimate and to track progress on.
Of course, the number of implementing task and their sum of (realtime)
estimates does (or should) correlate with story points. Over time you'll
learn how many story points you are able to get done during an iteration.
--
Cheers, Johannes
Agile Planning Team