“Guys, update your Sprint Tasks, the cut-off is 10am.”
“Hey Andrew, can you update your Sprint Tasks?”
“Are your Sprint Tasks up to date?”
If you’ve been on an agile project, no doubt you’ve heard these before.
Projects at ThreeWill follow a flavor of agile project management called SCRUM. SCRUM and agile processes are a deep topic, but I’ll summarize how we use it here:
- During the analysis phase of a project, we build a list of features which is called the Product Backlog.
- Next, each feature is sized. You could think of the sizing applied as small, medium, large, but in practice, we use a numbering system called story points which allow us greater granularity.
- The features are then divided into releases.
- Once the feature set of the first release has been determined, we are ready to begin Sprint 1.
- At the start of sprint 1, the team will determine the length of each Sprint, usually 5 or 10 days, and then commit to a set of features which can be accomplished during the Sprint.
- Each contributing team member will then commit to their capacity for the Sprint. For example, in a 5 day Sprint I might commit to a total of 40 hours, 8 hours each day.
- Last, each team member will create Sprint Tasks. Sprint tasks are each sized in hours.
The list of sprint tasks is the finest level of granularity used by our clients, the project team lead, and team members to have awareness of daily plans and progress for the project. This level of visibility allows everyone to become immediately aware if we are overcommitted or progressing slower than expected.
I can’t overemphasize what a great experience we have had with this on projects. I have had clients recognize over-allocation and immediately begin thinking of ways to trim back scope to fit into budget. I have had healthy conversations challenging the approach for feature implementation in order to arrive at a lower cost solution. I have worked with clients who were eager to be as efficient as possible in order to fit more features into the budget. In all cases, this level of visibility yielded great results.
But, with great knowledge comes great responsibility. This means that each person on the team needs to be trusting and helpful to one another. This means to not be offensive or defensive with the results of a sprint burn down. Instead, always look for ways to solve the problems at hand, which could include resource shuffling, scope reduction, or feature redesign.
It should be obvious to you why our clients, who are investing in technology, are in favor of this level of awareness. But what about the engineers who are the recipients of the reminders which I opened this blog with, why would they be motivated to contribute to building the sprint burn down chart?
If you are an engineer with passion for delivering working software, you know that you need space to deliver technology solutions. Not unlimited space necessarily, but rather you need predictable space.
Let me use a Stephen Covey quote to better explain what I mean by space, “Between stimulus and response is our greatest power – the freedom to choose. Space is that gap which exists between stimulus and response. This is the time in which we exercise our greatest creativity, make our best decisions, see our greatest accomplishments, and see the greatest intrinsic reward in our work.”
Sprint Burndown Charts are an enabler which can create this space. Clients who are fully informed and engaged in projects are less fretful and more constructive to the development process. A developer who knows that the tasks ahead are achievable, and that stakeholders are comfortable with the status, are more creative and productive.
So….Come on! Update your Sprint Tasks, Boyee!