Agile planning an iteration

  • 1,189 views
Uploaded on

Keypoint: planning for "One Step Further" !! …

Keypoint: planning for "One Step Further" !!

How to plan in an iteration including setting timing, participant, activities for an iteration planning meeting.

To process the conflit btw customers vs. developers...

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,189
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
9
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. User Stories Applied:For Agile Software Development – Ch 10. Planning an iteration Chen Jing Fung @iii 2011/6/23 Ref: other Agile solutions How to write, gather ideas, estimate the approach
  • 2. Planning an iteration • Best time: – the start of each iteration – Take a release(/planning process) one step further • Participant: – customers as well as all of developers • Key: – not much detail but enough planning for action-based – Ideal for planning a release • Activities for an iteration planning meeting Disaggregate into Accept responsibilitystart Discuss a story tasks (tasks) Estimate points done N (worth?) Y
  • 3. Discussing the stories start Discuss a Disaggregate into Accept responsibility (tasks) story tasks Estimate points done N (worth?) Y • Discussing the stories change An iteration planning – Opportunity to change the stories priority fromcustomer customers(C) &/or developers(D) • C: adjust priorities to deliver maximum businessdevelopers • D: ask questions until the story -> tasks – Not need every detail
  • 4. Disaggregating into tasks Discuss Disaggregate Accept responsibility (tasks) a story into tasks• Reason: N Estimate points Y – Not just one developer (worth?) – Stories descript the user/customer-valued functionality (not to-do list)• Tasks: Short bursts, Just-in-time Upfront design – Steps deign phase – Write on white board• Notice: – the tasks for updating the user guide & help system• Guideline for separating story into tasks – Difficult to estimate – Done by more than one developers (Ex. UI & lib) – Know a part of story is done => break it as a task
  • 5. Responsibility & Estimate+Confirm Discuss Disaggregate Accept responsibilitystory a story into tasks (tasks) Task ...Task John N Estimate points Y + developers (worth?)name • Commitments need to change – Task points are from story – We are in the same boat => team win!! points (each task <-> its member) • Key - accepting responsibility • Estimate & Confirm responsibility – Estimate points/tasks reliability!! reliability – One member accept his/her – Basic unit: individual tasks – Make sure no one over- – (team) progress through the committed iteration • Learning more about tasks – Procedure if over-committed • Find some work easier than 53 p-task/ • Keep all the tasks & hope planned 2weeks • Request someone to take – But some harder? (move to over!! • Talk with customer later iteration / ask for help) dropping/splitting a story
  • 6. Summary• Iteration plan take for release planning => one step further – For the iteration being started – Discuss each story & split it into its constituent task • Keep the relationship: stories → tasks (story points: week -> date -> hour) – Facilitate estimation • No mandatory size range for tasks (Ex. 5 hr/3 tasks) • Encourage developers to work other parts of story • One developer accepts responsibility for each task • Assess over-committed? – Cyclically estimating each task until reliability (story points)Ref: other Agile solutions How to write, gather ideas, estimate the approach