Introduction
I wrote a post a while back, about experimenting with estimates. This is a continuation of that, with reflections about my progress and thoughts about working as a consultant.
My Progress
Here is my Burn Down chart, for the number of stories left (as of 2/2/18):
Just as a refresher, graph shows the number of stories left on the y-axis, and the timeline in days on the x-axis. The blue zig zagging line shows the number of story points left, the red line shows how many stories were finished that day, and the yellow line is the ideal burn down (to finish the project by the 9th week, assuming 5 work days a week). The straight blue line is the trend-line that runs through the blue stories left line.
As you can see, I am 3 weeks, or 15 days, into my project. However, I am already behind, as denoted by the blue trend-line stretching out further than where the yellow line reaches 0 stories left. In order to catch up within the next week, I would need to finish 8 stories, which would look like this:
Basically, my velocity is denoted by the slope of the blue trend-line. If the slope is lower than the yellow line’s slope, and the blue line ends up above the yellow line, I am moving too slowly. If the slope is higher than the yellow line’s slope, and the blue line ends up below the yellow line, I am on track to finish faster than anticipated. Unfortunately, right now I am in the former category, and need to step up my game.
If you look at the Burn Down for the number of points left, the situation appears even more dire:
The slope of the trend-line here is significantly lower than the slope of the ideal burn down rate. This is mainly due to the fact that the stories I have finished so far have less points than most of the other stories in the backlog. However, my estimates in the backlog are much more conservative, and have a good chance of being lowered when moved out of the backlog, into the ready column. At the end of the project, it would be a good idea to normalize both charts (divide each number by the highest value), so that the two charts could more easily be compared.
The next section discusses some of the lessons I have learned about working as a consultant (from my “simulated” experience).
Working as a Consultant
As part of my apprenticeship at 8th Light, I have been working as a “consultant” with my two mentors, who also double as “clients”. Throughout my experience, I have made mistakes, but learned lessons as well. Here are some of the lessons:
- Communication is key
- Clarify expectations and acceptance criteria
- Justifying my estimates once they are done
- Not re-estimating stories once they are pulled out of the backlog
The following sections discuss these in more detail.
Communication is Key
A key part of my job as a consultant is to communicate clearly and regularly with the client (or clients). It’s important for me to understand what my client wants, and to communicate to the client how I can provide what they’re looking for. After I’ve started the work, I need to give regular updates on my progress, and keep my client aware of the status of the project, and involved in the direction of the project. And if I am falling behind or run into an issue, it’s important to let the client know as soon as possible, so the proper action can be taken.
Clarify Expectations and Acceptance Criteria
In order to provide exactly what my client is looking for I need to clarify and understand what is expected. Part of this comes from just asking questions until I have a clear idea of what must be built, and what features should be included. Part of it is codified in the acceptance criteria of my stories. The acceptance criteria should be detailed enough so that the client is confident I understand what they would like to have built, and I know how to implement the product.
Justify My Estimates Once They’re Done
Regarding estimates, ultimately I have the final say on what they should be. However, I must be able to explain how I arrived at them, and why they have the particular value that has been assigned (the PERT system, and my reasoning behind each estimate).
Not Re-estimated Stories Once They’re Out of the Backlog
That being said, once my estimates are done, and the stories are moved out of the backlog, I can’t change them anymore. That means that I really need to make sure that the estimate reflects the amount of work I expect the story to take (to the best of my knowledge, of course). One side note about that is that estimates are educated guesses, and can often be wrong, so I should account for that by leaning on the conservative side for stories that I am not 100% sure about.
Conclusion
Overall, I’m satisfied with the progress I’ve made so far on my most recent project, although I am keenly aware of the need to increase my velocity and speed up my rate of progress. I am excited for the challenge though, and hope to have good news to share in my next post.
