Identifying and communicating variation to partners

Get Started. It's Free
or sign up with your email address
Rocket clouds
Identifying and communicating variation to partners by Mind Map: Identifying and communicating variation to partners

1. scenarios

1.1. what

1.1.1. new

1.1.1.1. we learned/discovered that we need a new work item

1.1.1.1.1. i.e., item is not yet on the backlog

1.1.2. different

1.1.2.1. we learned that we need something different to what we first thought

1.1.2.1.1. i.e., item replaces an item on the backlog

1.1.3. bigger(/smaller)

1.1.3.1. we learned that a work item is much bigger than what it originally appeared

1.1.3.1.1. i.e., item on backlog multiplies into more items

1.1.4. no longer needed

1.1.4.1. we learned that we don't need a work item anymore

1.1.4.1.1. i.e., item on backlog can be removed

1.1.4.2. in this case, it's pretty obvious what needs to happen, so the call out can be less formal

1.2. when

1.2.1. Brief workshop

1.2.1.1. epic

1.2.2. Scoping stage

1.2.2.1. epic, user story

1.2.3. Development stage

1.2.3.1. epic, user story, change request

1.2.3.2. change occurs before the work item has been started, while in progress or after done

1.2.4. Iteration N/UAT/Beta

1.2.4.1. change request

1.2.5. Support stage

1.2.5.1. enhancement

1.2.6. NOT to be called out unless significant impact

1.2.6.1. defect, bug

1.2.6.1.1. these should be factored into our original estimate (and padded by the estimates of the other work items)

2. principle

2.1. Minimise bill shock by communicating any potential impact to time & cost forecasts early and often

3. proposed process

3.1. 0. Development kick-off

3.1.1. Set expectations

3.2. 1. Detect you have entered a time/cost impact zone (new, different, bigger, no longer needed)

3.3. 2. Call it out during the discussion (Please don't wait for a later occasion, because it's too easy to forget)

3.3.1. Some things you might say:

3.3.1.1. "As we are on Time & Materials, this <thing/idea/change> may have an impact on the time & cost of the deliverable/project."

3.3.1.2. "We will go away and estimate the difference in size and I will get back to you before our next session with the impact if any"

3.3.1.3. "If there is a size increase, would you want to remove an equivalent sized item, or would you be happy to go with an increase in time & cost"

3.3.1.4. "Note that our estimations are our current best guesses, so they are just a guide, so it's possible that we can fall on either side."

3.3.1.4.1. T&M are currently the optimistic estimates, so we are setting ourselves up to have conversations often (as we are often likely to miss the optimistic estimate

3.4. 3. Follow up

3.4.1. we communicate the impact on the time & cost estimate via the Iteration Report (burnup chart and backlog increase) or via an email template if it's a significant impact

3.4.1.1. What is the threshold of "significant impact"?

4. activity

4.1. backlog management (epics, user stories, etc)