Agilist Basics

by bishopofagile

Let’s examine a generic software project.

Firstly, the project needs to be broken down into manageable chunks – each chunk, in our particular Agilist sect, is known as a “Story”. The act of a developer implementing the Story is known by the Agilistas as “playing the Story”. Traditionally each story is initially designated by a post-it note stuck the the wall, although it’s now common to have an expensive “post-it notes stuck to the wall emulator” instead: GreenHopper is such a system and we used GreenHopper at money.moo.

Once you have a set of post-it notes stuck to the wall, the Stories are said to be “On Deck” and the next step is to flesh out each story with a concise description of what it actually means. This involves the BA’s (Business Analysts) and the PO’s (Product Owners) creating AC’s (Acceptance Criteria) for each Story. AC’s are simply lists of behaviors that the software should exhibit after the Story has been Played in order for the Story to be “Accepted”. In principal, the BA’s and the PO’s are experts in the software and fully understand what the customer will require in their UX (User eXperience). They will, as part of this process, ask the art department to produce “Comps” (graphical mock-ups) of each aspect of the Story so the developers know what their final product should look like.

Then, each story is allocated a “Point” score, which is a number that is supposed to indicate the amount of work involved in developing the Story. The more work required by a Story, the more Points it is worth. We’ll discuss the value of Points and how they’re calculated later on, but the number of Points a team can complete in an “Iteration” is known as the team’s “Velocity”. Velocity is related to, but completely different to “Capacity” apparently. Once you know a team’s Velocity you can use this value to plan for development deadlines. If you are mentally ill.

As stories are developed, a QA (Quality Assurance) team is employed to break them by finding bugs. The bugs go back to the developers to fix, and the QA team check them out again. This is an age old, and surprisingly effective, technique because the more bugs discovered before the customers get to find them the better. Obviously a good QA team will find more bugs than a bad QA team, but they instantly render themselves  unpopular with the developers (no developer likes to admit they created bugs) and the management (no manager likes the idea of the project being held up). Agile has solved this problem by not assigning a point score to bugs – consequently, in the Agile timeline, they take no time. If you ever find yourself with too many story points to complete in a certain amount of time (based on your “Velocity”), simply turn the stories into bugs and the problem vanishes! It’s like magic!

Even a complete simpleton would see the advantages of this as a way of measuring progress and performance. Whether this simpleton was capable of recognizing the number of ways the idea is profoundly flawed is questionable. For the benefit of readers resident in the class of complete simpleton, there should be an appendix containing explicit descriptions of the flaws at the end of this text.

All you need to know at this point is that, as far as the Agile Bishops are concerned, if your team has the “Capacity” to “Play” all of the “Stories” in a specific time-span, then the time-span is realistic. Don’t. I know. We’ll talk more later.