How to estimate and prioritize

This is an excerpt from the last chapter of my Building Data Products Book. At this point we've completed a number of iterations building up to a solid first pass at a sales analytics system. Borrowing from SAFe (don't @ me. I've also got plenty to say!) the next step is to take a break, continue to refactor, and think about what comes next. This is a good time to introduce some suggestions on how to prioritize what to work on when you have many possibilities. 

​SAFe (and many others) recommend the Weighted Shortest Job First (WSJF) method described on the blackswanfarming.com website as Cost of Delay. Good luck getting a group of people with their own priorities to agree on using actual dollar values to define value! You need to ease them into it by making the people who can assess the business value and urgency story point them, just like they made the developers use story points to determine the value of their work. (/snark)

Chapter 9: Final iteration - Innovation and Planning

With the completion of these stories, it’s tempting to declare success and start with the next development round. Don’t do it! Take time to step away for a while. Take the afternoon off, relax, and give yourself time to let all this work settle in. Let things run for at least a few cycles to look for issues you might have missed.
After the quick break, this time should be focused on these activities:

1. Note any bugs and possible solutions.
2. Identify potential support refactoring opportunities. These are true refactors. They don’t add new features. They make the code easier to support.
3. Identify potential performance issues and possible improvements.
4. Add to and update the documentation.
5. Identify feature enhancements.

In this Innovation and Planning phase, focus on the technical side of the product rather than the customer or business side. By establishing a dedicated block of time to work through these issues, you make it easier to keep ahead of them. Over time, it becomes easier to integrate these activities into the day-to-day development flow. Early on, as the team establishes itself, having this dedicated time is critically important. Without it, it is too easy to plow ahead building user features while technical debt piles up and eventually overwhelms the product. It is a delicate balancing act, but establishing clear boundaries early goes a long way to keeping the amount of work manageable.

Start this process by brainstorming stories for each of these five categories and assign them rough priorities and values. Then from this list, create a few separate stories to work on in this iteration and a few to backlog for future iterations.
Determine the priority of a task by ranking them by their cost of delay.  In this process, assign each story or desired outcome, three values. If you cannot assign actual monetary values, use proportional values across the set of deliverables. Good proportional scales could be a limited range (1–5, 1, 3, 5, 8, 13) or order of magnitude (1, 10, 100, 1000).

1. Urgency - How critical is it that this be done immediately?
2. Value - Is there hard or soft business value?
3. Duration - How long will this take? How confident are we in this estimate?

Bubble sort each deliverable by category. Based on the order, assign a value number (the modified Fibonacci sequence works well to break up any groupings) (1,2,3,5,8,13,21,34,55,89).

The individual scores don’t matter beyond prioritization. With this methodology, the highest value activities which can be completed in the shortest time receive the highest Cost of Delay divided by Duration scores ((Urgency * Value) / Duration).

Description	Urgency	Value	Duration	Score
Dynamic command to shut down local server before restarting.	1	1	13	1
Add metadata table to the db.	8	8	5	13
Add Entity relationship diagrams to the documentation.	13	13	8	21
Remove unused targets from the makefile.	3	3	1	9
Remove unnecessary tables from the deployed database.	5	5	3	8
Research / POC access to product cost API.	34	21	21	34
Research non-conformance query.	21	34	34	21

Based on the Cost of Delay scoring, the prioritization looks like this:

1. Research / POC access to product cost API.
2. Research non-conformance query.
3. Add Entity relationship diagrams to the documentation.
4. Add metadata table to the db.
5. Remove unused targets from the makefile.
6. Remove unnecessary tables from the deployed database.
7. Dynamic command to shut down local server before restarting.

Executing technical improvements
This iteration is shorter and less formal. If the team feels like a basic task list sufficiently communicates progress, then this is a good time to experiment with less formality. Another strategy is executing a portion of the prioritized stories. This creates a smaller and more focused queue. In this example, focus on completing the first few tasks as quickly as possible. Once complete, start planning for future iterations.
The first two look like good candidates for a future development iteration. They have long durations, and most likely, many unknowns and potential issues. Therefore we should push these toward the bottom of the list for this short planning iteration.
The rest of the list look like good candidates. We’ll pick the first three to start. Once complete, we start the planning process for future iterations.

Read More...