Agile Development Process

Google+ Pinterest LinkedIn Tumblr +

Agile Development Process

Internal Iteration Planning Meeting Agenda

Timebox meeting

Discuss meeting agenda

Review previous iteration

1. Do Kaizen Process

Review stories for current iteration


1. High risk stories

2. Big point stories

3. Stories with dependencies

4. Stories that need prototyping

5. Stories that have questions for client

Plan iteration

1. Calculate remaining capacity (meetings, vacation, etc.)

2. Determine target velocity

3. Allocate points to development weeks

4. Assign stories to weeks based on priorities and availablity

Weekly Planning Meeting

Meeting Facilitator

* Before the meeting begins, call Jackie to confirm stories to be worked on and their priorities

* Gather appropriate stickies, story cards, laptop, pens.

* Determine Pair Hour Capacity using the formula:

((Days * Hours in a Buffered Day * People) – Hours out)/2 Usual values:

-4.25 Days (assumes 1/2 day design meetings, 1/4 day Kaizen)

-7.4 Hours (assumes 20% buffer)

-8 People (assumes 7 developers + 1 Bonnie + 1/2 Bruce + 1/2 Rex)

-Hours out includes non-BC meetings, time off, etc.

* For each story do Task Breakdown

* Only do a Task Breakdown for whole pieces of working functionality–no partial stories

Sticky Wrangler

1. Puts story card on the wall

2. Finds and organized stickies

3. Posts sticky for story being discussed

4. Keep track of discussed and yet-to-discuss stickies

5. Marks any changes or clarifications to stickies with different color marker

Spreadsheet Scribe

1. Make sure the stories being discussed are in the project sheet and date marked for this iteration

2. Confirm point value for stories

3. Enter total estimated task hours

4. Check that estimated task hours are in line with point value

Time Keeper

1. remind the group how much tme we’ve spent

2. if need be, set the timer

BA Tasks

1. Record task hours

2. Arrange meeting with client for a quick story status update, noting stories that tasked out over or tasked out under or are low confidence

Kaizen Process

1. Choose facilitator; prep for meeting

2. Have people put in their hours for the day.

3. Print out Task Kaizen Summary and highlight tasks that went over or under.

4. Clean off whiteboard

5. Put Prime Directive Prime Directive on the whiteboard.

6. Draw calendar on the whiteboard.

7. Make sure all supplies are ready

8. Find old Kaizen Cards and put stickies on them.

2. Set the stage

1. Set time frame for meeting

2. make sure everyone agrees to the Prime Directive.

3. Review process

4. Everyone say one word that summarizes the last week

3. Collect data

1. Print simplified spreadsheet of the prior week’s progress

2. Make a calendar to refresh memory of the week’s goings-on

3. Review tasks from last meeting

4. Brainstorm / collect all love/hate/defects/kaizen for discussion

4. Prioiritize

1. Everyone gets five votes

2. Ranks card from most to fewest votes

3. Discard anything that didn’t get at least one vote

5. Generate insights (for each card)

1. Discuss why its a problem and the root cause of why this happened

2. Generate actions that can be taken

3. Write task on separate task sticky

6. Decide what to do

1. Have people sign up for actions and make tasks

2. Discard any task that didn’t get a vote

7. Close meeting

1. Determine which project to bill the Kaizen to

2. Get quick feedback on the kaizen

3. Make sure tasks are somewhere visible for the next week.


* beer

* bottle opener

* big whiteboard or at least big stickies

* big sticky or whiteboard for recording final tasks/ideas.

* whiteboard markers or sharpies

* cards

* med stickies

* small stickies

* pens

* timer

* tape

Implementing a Story

1. Update project

2. Review technical note cards from Weekly Planning Meeting

3. Review tasks and test

4. Determine general approach and first steps

5. Look for reuse/refactoring opportunities

6. Look for opportunities to create functionality for easy testing

7. Consider questions from Problem Frames to assist in design

8. If working on the production branch, merge with trunk after completing the story

During Development:

* If solo, cry for help

* If a pair, cry for help

* If you have a question, ask

* Sketch where necessary to clarify approach/direction and common understanding

* Agressively make TODO’s

Committing a Story


1. Run build locally

2. Update from SVN

* resolve conflicts

3. Run build locally

4. Check project status

* add files not in SVN

5. Commit Project

6. Run build on Build Box

7. Return to Cubby


While waiting for the build:

* Ask pair how things went.

* Any kaizen issues?

* Any blogworth issues?

* Cleanup desk

* Ask others how things are going.

Reviewing a Story

* Print out photo of relevant Stickies

* Cross out features/requirements as you test them

* Use staging data

* Test using 1024×768 on browser.

* Confirm that no TODO’s remain.

* Usability

* Log in as correct user type (not always admin)

* Test Happy Paths

* Test Sad Paths

Finishing a Story

1. Eliminate outstanding TODO’s/Index Cards

* Move them to Slack Time if necessary

2. If Solo, do a code review.

3. Review story yourself (Reviewing a Story).

4. Review with some from Boston (Reviewing a Story).

5. Toss big stickys

6. Check off on tracker

End Of Mini Iteration Checklist

It’s Friday, you’re out of tasks and you don’t know what to do?

1. See if there is any work on remaining tasks that can be split out.

2. Make sure there are no more TODO but run anyway.

* check the ‘pending story’s too just to make sure nothing slipped by.

3. Eliminate TODOs from the code base.

4. Clean up TODO index cards left on tables (look around).

Once all of those are done, hit the Deployment Checklist.

After that, dig in to Things To Do If Your Looking For Something To Do.

Starting a Task

* take note of time that you started

* click around the web app to examine existing functionality

* look for related fit tests

* discuss design with your partner

* implement the task to the best of your abilities

* note the end time

Finishing a Task

Checklist for completing a task

1. Clean up code and/or refactor

2. Eliminate TODOs

3. Tear up Index Cards

4. Commit

5. Cap the box

Minimums required to estimate a story:

* 3 People, 2 of which must be developers, one of whom must be a senior developer

* Note cards

* Estimating cards – 1 deck per person

Process of Estimating

1. Read the story out loud

2. Discuss it

3. Call a vote

4. Each person holds up a card so that only he/she can see it

5. When everyone has visibly chosen a card, turn them over


1. If story is 8 or over, break into smaller stories

2. Identify high-risk stories – give confidence level

3. Give worst-case scenarios for high-risk stories

Writing Fit Tests

Types of FIT tests:

1. rule tests – simple, very focused test that demonstrate a single business rule

2. full scenario (aka end-to-end) tests – tests several aspects of the system: xwork actions, DB, etc.

3. realistic output tests – tests different system output to the user based on real/realistic data (i.e. invoices tests)

Steps for writing a test:

1. sketch the test on a whiteboard or big sticky

2. create an HTML file

* leave title blank

* make file name and page heading the same

* make sure the CSS reference is working

3. outline the business rules in bullet points at the top of the test

4. start with text describing what you want to accomplish with the test

5. use headers (h3) to denote subtests, not for explaining what’s happening

* review big sticky line by line and make sure everything is in a FIT test

* toss sticky

Reviewing with client:

1. Email FIT tests to client (subject should be of the form ‘FIT Test – |name of test|’

Handling Incoming Requests

Submitting a request

1. Phone – Whenever possible, a short request from the client should arrive as a phone call. All High Priority items must include a phone call.

2. Email – When sending requests or following up on request by email, please use the following guidelines:

* Subject line: PRIORITY – PROJECT – Title

* In the body of the email include: summary of issue, screen shots, description of circumstances of when this occurs, etc.

* List anyone we can contact for further information/clarification

* Send email to


* High – Stop regular development and address the issue ASAP

* Medium – Should be scheduled into the next day’s work

* Low – Can wait until next week

Processing a request

1. If the question/request can be handled immediately without interruption of work, just do it

2. If non-trival, do the following based on the priority level

1. With the team, discuss the request (if more information is needed, contact client)

2. Get someone to sign-up for the task (Owner)

3. Estimate the amount of work

4. Project Coordinator sends estimate to client and confirm estimated time frame

5. Owner signs up contacts client directly with questions, etc. and emails the client when the issue has been resolved/completed (CC Project Coordinator)

6. Owner updates board with status


About Author

Leave A Reply