myIMD pre-kick-off

Get Started. It's Free
or sign up with your email address
Rocket clouds
myIMD pre-kick-off by Mind Map: myIMD pre-kick-off

1. structure

1.1. 3 week sprints

1.2. Activities

1.2.1. planning

1.2.1.1. 2 parts

1.2.1.1.1. explanations of stories

1.2.1.1.2. breaking down stories into tasks

1.2.2. stand-up

1.2.2.1. < 1 min per question

1.2.2.1.1. What did I do yesterday?

1.2.2.1.2. What will I do today?

1.2.2.1.3. What blocking issues do I have?

1.2.2.1.4. What is your confidence, on a scale of one to ten, that the team will accomplish the goal of this sprint?

1.2.3. refinement

1.2.4. review

1.2.5. retrospective

1.2.6. clearing

1.2.6.1. once a week for an hour at a fixed time

1.3. Release planning

1.3.1. steps:

1.3.1.1. sketch a preliminary roadmap

1.3.1.1.1. an estimated, ordered, prioritized product backlog

1.3.1.1.2. the team velocity

1.3.1.1.3. a sprint timeline

1.3.1.2. add a degree of confidence

1.3.1.3. include dates and adjust as needed

1.3.1.3.1. lower and upper range

1.3.1.4. update the plan every sprint

1.4. block hours

1.4.1. 1 hour in morning everyday

1.4.1.1. 10:00 -11:00 Swiss time

1.4.1.2. 10 mins standup

1.4.1.3. 50 mins Q&A with Philippe

1.5. Definition of "Done"

1.5.1. Random Examples (not ours)

1.5.1.1. Done with a Story

1.5.1.1.1. All code checked in

1.5.1.1.2. All unit tests passing

1.5.1.1.3. All acceptance tests identified, written and passing

1.5.1.1.4. doc auto-generated

1.5.1.1.5. functional tests pass

1.5.1.2. Done with a Sprint

1.5.1.2.1. All story criteria plus

1.5.1.2.2. example 2

1.5.1.3. Release to Staging

1.5.1.3.1. All sprint criteria plus

1.5.1.4. Release to Production

1.5.1.4.1. All staging criteria plus

1.5.2. We need to define one for us

2. responsibilities

2.1. raise the alarm if you are stuck and can't make progress (Stand-ups but judgement call)

2.1.1. don't be afraid to say if you are unsure or don't know => goal is to be transparent and have a safe environment

2.2. if you break the Continuous Integration (CI) build, you fix it ASAP

2.3. favor close collaboration/communication with other members

2.3.1. Philippe being the exception with block hours

2.4. code review of every line

2.4.1. how do we do that?

3. desirables

3.1. defect rating system

3.1.1. p0

3.1.1.1. catastrophic

3.1.1.1.1. major functions of the system are non-operational

3.1.2. p1

3.1.2.1. high

3.1.2.1.1. major functions of the system are non-operational

3.1.3. p2

3.1.3.1. moderate

3.1.3.1.1. system usability impaired

3.1.4. p3

3.1.4.1. low

3.1.4.1.1. minimal impact

3.1.5. if p0 or p1 is found, you have 1 hour to accomplish the following tasks:

3.1.5.1. stop the work you are doing

3.1.5.2. communicate the problem

3.1.5.3. identify the root cause of the defect

3.1.5.4. fix the cause

3.1.5.5. update all tests (unit, functional and acceptance tests)

3.1.5.6. ensure they are passing

3.1.5.7. check code in and push so CI picks it up

3.1.5.8. if this cannot be done within 1 hour, do the following

3.1.5.8.1. stop work

3.1.5.8.2. log the defect in Jira

3.1.5.8.3. continue to fix bug

3.1.5.8.4. once fixed, write the steps taken to get it fixed in Jira and log the time taken

3.1.6. if p2 or p3 is found

3.1.6.1. log defect in Jira and put it on product backlog for review and prioritization by product owner

3.2. engineering practices and standards

3.2.1. Continuous Integration and frequent check ins

3.2.1.1. when red (build/tests fail), alarm is raised and goal is to fix it ASAP

3.2.2. Automated system and acceptance tests

3.2.3. Refactoring

3.2.4. possibilities

3.2.4.1. Pair Programming

3.2.4.2. TDD

3.3. pomodoros

3.3.1. http://tomato-timer.com/

3.3.2. especially if you have interruptions

4. technical understanding

4.1. system scope?

4.2. list of devices

5. admin

5.1. sharepoint share

5.2. jira project

5.3. block working hours