A look back at the best from a year ago.
How To Use Timeboxes for Scheduling Software Delivery
Roger had a great suggestion in the comments to our previous two-part post on scheduling requirements changes based on complexity. Roger pointed out that we had not explained what timeboxing is, but implicitly used the principles of timeboxing in our proposed process. In this post, we explain timeboxes and how they are used.
Scheduling requirements changes – part 2
This process goes against agile principles on paper, but makes teams more agile in practice. Scheduling delivery of a project is an exercise in managing complexity. Scheduling changes to the requirements on the fly is really only marginally more difficult. The key to managing changes is to set expectations with our stakeholders. By defining rational deadlines for change requests, we assure ourselves that we can manage the changes. We also demonstrate responsiveness to our stakeholders. Rational deadlines are not arbitrary deadlines nor are they unreasonable deadlines. Deadlines that vary with the complexity of the changes are rational, easy to communicate, and easy to manage.
Scheduling requirements changes – part 1
Software product success requires timely delivery. There are many factors that influence our ability to properly scope, schedule, and deliver software. When we propose changes in requirements we introduce risk to the schedule. We can set reasonable expectations for our stakeholders while maintaining a realistic work environment and schedule. In part 1 of this post we detail a requirements triage process that organizes requirements by complexity and allows us to set and meet expectations of delivery.