As the development team's "Scrum Master", I am often asked about the process of breaking requirements down into scheduled tasks (anything related to implementing or verifying a Requirement). This is one of the areas most teams struggle with when adopting Scrum or any other Agile process, but there are some who feel our team is more rigid in this area than others, because we adhere to Joel Spolsky's methods of Painless Software Schedules. We use Team Foundation Server instead of Microsoft Excel, but we are governed by the same rules and principals recommended in Joel on Software.
In an attempt to further clarify, here are five broad reasons why this method has helped our development team deliver better code, faster than ever before.
1) To create tasks, you must plan well.
Tasks are usually the output of a good iteration planning meeting. Even though we can rely somewhat on earlier numbers to get a sense of what a team might be able to achieve in subsequent iterations, breaking requirements down into development tasks/hours allows the team to leverage what they learned during a prior sprint in terms of some requirements being potentially larger or smaller than originally believed.
During planning, openly discussing development tasks gives all team members a view of what will take place while implementing the requirements selected for the iteration. During that discussion they can help each other clarify and improve their schedule, discussing the lesser known areas of the code, database, etc to help other team members learn and ultimately become more productive.
2) Tasks allow you to estimate when the work will complete.
Having tasks estimated in hours enables the team to discuss (during the Daily Stand Up meeting) why certain tasks might be taking longer than planned, why some tasks were overlooked when a requirement was initially discussed, and why some tasks were ultimately not required. During this daily exchange of this information, it quickly becomes apparent where developers may be struggling with a given task and may need help.
It also enforces thinking more thoroughly about tasks needed to complete a use case and improves estimating during subsequent iteration planning meetings. This allows the team to get an earlier sense of whether the goals planned for a given sprint will be achieved and allows the team to consider adjustments sooner.
3) Tasks create transparency, inviting team collaboration in problem areas.
Defining and estimating tasks makes team commitments to an iteration public knowledge and increases the sense of urgency in getting better at task definition and estimation. It also can help with maintaining a sense of focus on agreed upon tasks and indirectly trims waste related to gold-plating—or as Kevin likes to say, "running the glass through the mill too many times". It can encourage team members to seek assistance on tasks they might be struggling with as some 2-hour task still isn't done after a couple of days effort and the teams velocity begins to become negatively impacted.
Developing without visible tasks can lead to requirements not being met. Without visible tasks, the team loses the ability to provide assistance (since nobody knows where help is needed) and overall iteration and ultimately release predictability suffers.
4) Tasks promote shared learning.
Discussing, defining, estimating and tracking tasks allows the entire team to learn about the problem domain, especially when the domain or parts of it might be new to certain team members. It also helps all team members become better about planning the work needed for all requirements and helps them to become better estimators of tasks.
And finally...
5) Tasks encourage better design.
Thinking through a plan of attack for implementing use cases and scheduling tasks to achieve, tends to create a higher level of focus and optimize overall productivity. It also facilitates design discussion often resulting in better and more complete requirement implementation.
No comments:
Post a Comment