Scribd
Upload
10 views7 pages

Week 8 and Week 11 - Iteration Planning

Uploaded by

huo1010john
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
10 views7 pages

Week 8 and Week 11 - Iteration Planning

Uploaded by

huo1010john
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

School of Engineering Technology and Applied Science

Information and Communication Engineering Technology

Software Development Project I (COMP231)


Iteration Planning (15% split 7.5% for Iteration 1, 7.5% for
Iteration 2)
Due Date: Sunday of Weeks 8 (Iteration 1) and Week 11
(Iteration 2)
by 11:59pm (late penalty: 20 pts per day)

CONDITIONS BEFORE ACTUAL DEVELOPMENT

Before actual coding can begin per iteration, the entire team meets to:

1. Discuss each story for the upcoming iteration only.1


2. Disaggregate the story into its constituent tasks.
3. Allow developers to accept responsibility for each task.
4. Allow developers to estimate, using ideal hour of work 2, the tasks they are going
to eventually accept to make sure they are not over-committed.

DISCUSSING THE USER STORIES

A few things to note when discussing the stories:

● The Customer can change the priority of stories during this time, but avoid
changing story priorities during the iteration.
● The Customer should start with the highest priority.

● Developers should ask questions until they understand the story sufficiently to
disaggregate into constituent tasks.
● It is not necessary to understand every detail of the story because that would be
inefficient. The Developers will be able to work the fine details of the stories with
the Customer after the planning meeting.

1 Stories should already have most of the acceptance tests identified.


2 Also known as ideal developer hour.
DISAGGREGATING USER STORIES INTO TASKS

A few things to note when disaggregating into tasks:

● Although stories are small enough to serve as units of work (i.e., between one to
five hours of ideal time), disaggregating them into even smaller tasks will either
allow multiple developers to work on a given story (leveraging the expertise of
individual developers), or because splitting the work is the fastest way to
complete the story.
● Stories are descriptions of customer-valued functionality; they are not to-do lists
for developers.
● The act of converting a story into its constituent tasks is often useful because it
helps point out tasks that might have been forgotten.
● Disaggregation into tasks happens in a group setting, the entire strength of the
team is brought to the effort.
● Disaggregating stories into tasks - which can only be done with at least a minimal
design in mind – allows short bursts of just-in-time design.
● Elect someone on the team to write tasks that comprise a story as they are called
out. The person writing the tasks is also expected to participate in the calling out
of tasks.

ACCEPTING RESPONSIBILITY

A few things to note when accepting responsibilities:

● Someone on the team needs to volunteer to perform each task.

● If pair programming, associate a single name with each task.3

ESTIMATING DISAGGREGATED TASKS

3 I usually find this practice difficult to simulate in an academic environment.


At this point the tasks should be small enough that they can be estimated with some
reliability. But, if not, don't worry about it. Take a best guess at the duration of the task
and move on. The entire process of discussing a story, disaggregating it into tasks, and
accepting responsibility for the tasks per story should look like the sample shown in
Table 1.

The fourth column is not part of the course textbook but should be recorded; it is the
actual ideal hour of work it took to complete the task. If there are major discrepancies it
took to complete the task, then discuss why that is the case.

Table 1: Disaggregated tasks per story [1].


Video(s) Report
There is a minimum of two Iterations per software release. However, your team is
required to submit video(s) for only one iteration planning meeting; the video(s) should
document the following:

1. Introduction made by each team member and his/her role and absenteeism
noted. [3 pts.]
2. Demonstrates the workshop is led by the Agile Customer. [2 pts.]
3. As a team, discuss each story before disaggregating the story into its constituent
tasks. 25 pts. divided by the number of stories for the given Iteration will be
deducted for each story whom’s constituent tasks are not disaggregated. [25
pts.]
4. As a team, disaggregate each story for the upcoming Iteration into its constituent
tasks. 5 pts. will be deducted for discussing stories in later Iterations. 1 pt.
deduction for each story whom’s constituent tasks are not disaggregated. [10
pts.]
5. Demonstrate that task ownership is done voluntarily by each team member. 1 pt.
deduction for each task ownership that is NOT voluntarily taken by a team
member (i.e.,avoid assigning a task to another member). [10 pts.]

[Total: 50 pts]
Written Report
Your team is required to submit tables similar to the one found in Table 1 for each story
per iteration. The write-up4 should include the following:

1. Demonstrate that task ownership is consistent (i.e.,leverage each member’s


specialization and expertise). 1 pt. deduction for inconsistent task ownership per
occurrence. [5 pts.]
2. Demonstrate that tasks estimations are consistent (i.e.,similar tasks should have
similar estimates; hint: triangulation). 1 pt. deduction for inconsistent estimates
per occurrence. [5 pts.]
3. Include a table of disaggregated tasks per story similar to the one shown in Table
1. 5 pts. deducted for each missing table. [25 pts.]
4. Submit two Iteration plans. 7.5 pts. deduction for each missing Iteration Plan.
[15 pts.]

[Total: 50pts]

4 All write-ups are required to be in essay format (the numbered list acts only as a checklist to ensure
your writeup contains all the required points).
Submitting your work
● Submission is via Ecentennial’s Dropbox.

● Do NOT archive (i.e., zip) your submission. Work submitted as a zipped file will
automatically be deducted by -10 points for this assignment.
● For video submissions, a link to the video is required. The video should allow for
streaming. Videos that require me to download it will result in 20 points being
deducted for this assignment. NOTE: links to videos should not be public links in
order to protect the privacy of all participants.
REFERENCES

1. Cohn, Mike. 2004. User Stories Applied: For Agile Software Development,
Addison-Wesley Professional.

You might also like