| 148 | | Assigning different classes of service to different work items is an easy way of creating a simple and transparent approach for the team to self-organize around the work and to meet the needs of the business by making work-item value, risk information, and policies explicit. |
| | 147 | * Classes of service are a powerful way to make your policies explicit around the service level for certain type of work. |
| | 148 | * Assigning a class of service to a work item can influence the work item: visualization, prioritization, impact on WIP, and workflow. |
| | 149 | * Classes of service help the team to self-organize around |
| | 150 | * Work selection and scheduling |
| | 151 | * Work distribution |
| | 152 | * Making sure the work capacity is distributed as decided |
| | 153 | * Common classes include |
| | 154 | * Urgent (or Expedite) - Prioritized over other work |
| | 155 | * Fixed Delivery Date - Needs to be completed on or before a certain date |
| | 156 | * Regular - Normal items, increasingly urgent, pulled FIFO-style |
| | 157 | * Defects - Rework produced by bad quality (you want as few of these as possible) |
| | 158 | * Intangible - No tangible business value now, but later: paying off technical debt |
| | 159 | * You should use classes that suit your needs and situation, using the examples in this chapter as inspiration. There’s no one right answer for everyone. |
| | 161 | === Planning and Estimating |
| | 162 | * Find the right time to plan - not too early nor too late, just in time: |
| | 163 | * Order points are one way to run event-driven planning. |
| | 164 | * Planning more often involves stakeholders around you more and builds trust, but it can also be costly. You need to balance it so that you plan with the right frequency. |
| | 165 | * Using Disneyland wait times is a way of showing expected delivery times. |
| | 166 | * Plans and estimates are often requested by others around you, extend the workflow upstream and downstream. |
| | 167 | * Estimating in exact terms is much harder than giving relative estimates, so prefer doing relative estimates: |
| | 168 | * Story points and T-shirt sizes are two common ways of doing relative estimates. |
| | 169 | * Estimation techniques: |
| | 170 | * A line of cards |
| | 171 | * Planning Poker |
| | 172 | * Goldilocks |
| | 173 | * Cadence is the natural rhythm or heartbeat found in your process. In iteration based processes, there are natural cadences when iterations start and stop. |
| | 174 | * With kanban you can have the cadences you see fit for activities: reviewing, planning, demonstration, and retrospectives. You don’t have to tie it to the flow of your work. |
| | 175 | * Need for plans and estimates: |
| | 176 | * Teams that use kanban see the need for detailed plans decreasing with the tightening of feedback loops. |
| | 177 | * Customers don’t want plans and estimates; they want business capabilities. |
| | 178 | * Estimating and making plans is useful as long as you’re uncovering new information. |
| | 179 | * The #!NoEstimates movement talks about abandoning estimates altogether and finding effective ways to work without estimates. |
| | 180 | |
| | 181 | ==== Planning Poker |
| | 182 | 1. Have a domain expert explain the requirement in question to the team, to ensure that everyone understands what it’s all about. |
| | 183 | 1. Perform the following estimation rounds, and only continue to the next round if you aren’t in agreement of the size of the estimate: |
| | 184 | * Round 1—Conduct silent voting using cards. No discussion, but cast votes: on the count of three as described earlier, for example. |
| | 185 | * Round 2—Let people think for a minute or two before doing a new silent vote, still without discussion. |
| | 186 | * Round 3—Let the team members explain why they voted as they did, and then vote again. |
| | 187 | * If you’re still not in agreement, then park that story for a separate session, and continue with the next requirement. |
