Executable Requirements: Define Done
Preface - Define Done
Thank you for taking a look at Executable Requirements: The Book! It is my hope that you find something here that makes your software project better.
As a software engineer developing a variety of software projects over the past 3 decades I have been fortunate to have worked on some great applications and with great engineers. I am always humbled by the great engineers and people that contribute selflessly and tirelessly to the software development community and am indebted by the great thought leaders of this incredible period where we have gone from literally no personal computing, no internet to a world where all but a few use computers on a daily basis and we can not imagine a world without the internet.
I'm not sure if this is true or not, but it's true enough for me, I have been blessed to work in an area in the Denver/Boulder area which I consider the epicenter of the Agile movement. And, while it's true that Iterative and Incremental approaches are nothing new, the recent XP, Agile and Lean focus has led to an increased awareness of best practices for developing software that is excellent and which is delivered to the market as early as possible. And while the practices of XP have taken the development community by storm, there is still a lot of misunderstandings about how to do scrum well and a lot of misinformation about what scrum is.
One thing that scrum and agile is not is an ad hoc process, cowboy coding or license to thrash. Scrum is an incredibly accountable development model. In any other process I can think of, if you asked toe developers to do task braskdown and daily status, they's collectively scream "foul" and "please don't micro-manage us!". Yet in a functioning scrum team there is no wailing or gnashing of the teeth, they're glad to do it. Why? Because they're self-organizing, accountable to each other and working on the things that have the most value for the organization.
Still, there is a lot of room to get better and good scrum teams are constantly looking for better ways of doing things and increasing thier agility. As a consultant in a company that specializes in agile process transformations I have had the opportunity to consider the behaviors of teams, assess their ability to work in an iterative modality (agility) and make recommendations for getting them to the next level. This book represents the best practices we have come to use.
One of the major tenets of planning on agile teams is the concept of "Velocity". Velocity is simply the rate at which developers complete work measured against a backlog of work that has been estimated in relative size units, or "story points". That is, if the sum of the estimations for all the stories in the "release" or "product" backlog is 100 story points a team averaging a "velocity" of 10 story points per iteration can do rough forecasting for when the software will be ready to release. However, determining velocity sprint over sprint is easier said than done, if a glld strategy is not defined. One critical aspect to our ability to assess velocity to to understand how many stories are actually 'done' in any sprint. Stories that are partically completed or where defects are carried forward in the plan dilute the precision and, with vague understanding of where and how much of this 'technology debt' a team has incurred, it is never clear what the velocity is and just where the team is on it's release burn down.
In addition to being 'done' for a sprint in an incremental development model, where we often refactor towards greater value, we'll make changes to the source that previously was done and, without being able to know if we're still really done with a user story we'd accepted in an earlier sprint, this ambiguity (and risk) can accumulate over time and, despite our diligence with the daily standup meetings, the agile team finds itself with quality issues and delivery challenges.
Executable Requirements is far more than just defining user stories as automated acceptance tests. The quest for their effective implementation takes us through other best practices. As an engineering director, manager and software engineer on teams that have delivered world class, award winning products, I have also seen extreme challenges that could have been much better mitigate through the use of any of these best practices which take pages from each of the following page books and represent a powerful approach to end to end issues in any software development life-cycle.
- Agile Design
- Requirements expressed as User Stories
- Domain Driven Design
- Ubiquitous Language
Executable Requirements - Test Driven Desing
- Design Patterns
Agile Planning and Just in Time Requirements
In an incremental development model we only elaborate details as we need to and defer details as long as possible. We do this so that we do not waste precious time articulating details of features, tests and design for user stories that we'll never deliver.