In part 2 we looked at a method of recording information about the requirements that is structured and consistent and can be done in a repeatable manner with relative ease. This is facilitated now by my new website CardConversationConfirmation.com. This tool allows your team to start recording your requirements in this form and its simple to use it in conjunction with PlanningPoker.com to obtain your estimates. In combination these tools are great for distributed teams as they are both accessible on the web and free to use.
In order to deliver the requirements there is no need to record any additional information other than the Card, the Conversation and the Confirmation, at least in terms of information that needs to be shared across the entire team to make this a success. There may be some KPI and executive reporting to be done and the testers may want to produce more detailed scripts but the CCC information will satisfy every stakeholder that the requirements are well understood and articulated.
Next comes Work Flow; the processes or the stages, indeed the lifecycle of a User Story from its initial conception to its deployment on the production platform. To examine work flow we will refer to the following diagram.
The boxes in this diagram are colour coded to group activities. In this part we will look at how governance intersects the development process but a more detailed look at governance comes later. Here we will focus on the other 4 categories of activity. For a given user story its life cycle progresses through these activities following the gates in order.
Card or User Story
The first step in the agile work flow is to take a requirement and express it as a User Story on a Card. This should be written in the structured form - AS A user I WANT some software function SO THAT i can realise some benefit. This structure has special benefits which you can read more about here in a separate article. User Stories or cards will accumulate as the customer detail their requirements, for now these should be entered into the project ready to be estimated.
Gate 1 - Customer Approval
The gates are steps with in the agile work flow that require the customer's approval or sign off. The first decision for the business is whether to send a user story into the estimating process. Its doesn't make sense to estimate all the user stories for a variety of reasons such as they may not ultimately be required and therefore it would be wasteful to estimate those, and anyway estimating takes time so its important not to ask for too much at once because it may not all get completed or it may be rushed and hence unreliable. The customer or product owner needs to consider which stories need to be estimated based on commercial priority.
Estimate
This first estimate in the agile work flow is about understanding relative size so that the customer and product owner can review priorities to facilitate the definition and scheduling of sprints. These estimates should be done in story points, say a scale of 1 to 20 where 1 is small and 20 is very large. For a given set of user stories each should be weighed against the other and assigned a score on this points system. From one estimating session to the next what we learn about the estimation skills of the team and the types of tasks involved in delivering various types of user stories, should be used as feedback into this process so that estimating is relative between all user stories and is a continually improving system.
Note that while estimating is in progress there is much Conversation about the user story - the more the better at this stage. On top of that its necessary to start filling out some detail on the Confirmation too - a good estimate accounts for what needs to be tested. If there are items of conversation that cannot be concluded - such as "when will we receive the data" then it may still be possible to estimate but these should be raised as risks. Note from the diagram that Conversation and Confirmation are at the heart of the agile work flow and continue to be updated throughout.
Prioritise
Once a user story has been estimated it can be re-assessed for priority. This is an important step because often the estimate can indicate to the customer that the cost is to high for the benefit the user story will deliver. It may therefore be discarded, or the customer may decide to make a subtle change to the requirement and write a new user story. But where the customer is happy with the estimate against the benefit they may still decide to raise the priority if it is less expensive than they thought or reduce the priority of its more expensive.
Define Sprint
With all the information required to understand the user story's priority the next step is to define the next sprint. This should be the next block of user stories that can feasibly be delivered in the next development period. It also needs to be a block that is potentially deployable so at this stage the dependencies between user stories comes into play. If at first it seems that the first 12 items on the priority list can be delivered but number 9 can't be delivered without number 14 there are some observations and choices to make. First the prioritisation process should have picked this up and they should have been prioritised in the opposite order - never the less this does happen, especially when 9 is a focal representation of the requirement where as 14 is a minor requirement that supports it. Either remove 9 and leave it until the next sprint replacing it for now with something further down the list of similar size, or remove an items the same size as 14 and bring it forward into the current sprint.
Gate 2 - Sprint Sign Off
Gate 2 is about the customer signing off a sprint and saying that its ready to commence. Taking a leaf out of the scrum book at this point, gate 2 is declaring that nothing can change in this sprint now that its started and this needs to be upheld as far as possible. However we all know that the customer's priorities can change in the space of 4 weeks so its important to have an emergency procedure that can be called upon if necessary but this needs tight governance around it if its to work well.
Task Planning
Once the sprint has started there needs to be some task planning done - this is the second estimating stage in the agile work flow and differs from the first in two ways.
1. Define tasks for each user story
2. Estimate the tasks in ideal days
For each user story there may be several tasks that need to be developed - these should be recorded within conversation and confirmation but can be recorded elsewher if so desired - and its important to understand how long they will take and so should be estimated in ideal days. Then a schedule and critical path for the sprint can be created.
This needs to be on the first day of the sprint there isn't any need to do it before. In this phase it is possible to use the confirmation section to lead the way - each confirmation entry is a test that needs to be passed - a good way of building a schedule is to determine when each confirmation will be ready for testing through out the cycle.
Build and Test Cycle
Finally the producers get to work creating the software and making sure it delivers the requirements. During this phase of the agile work flow there are likely to be some new questions about the work and hence more conversation and maybe more confirmation.
Items must be built according to the schedule. The testers will look to see when the first confirmation items are scheduled to be ready and can begin to prepare scripts that they will use to test them so the designers and developers need to get started to be sure to deliver on time. This process generates many small cycles with in the sprint somewhat akin to a Test Driven Development approach with some flexibility around discipline where appropriate.
Gate 3 - Customer Review Sign off
The third and final gate in the agile work flow is where the customer reviews and signs off the work. A customer review can take place anywhere in the sprint but normally its wise to have a customer review stage at the end of the sprint as sort of a regression customer review to obtain sign off on the whole sprint.
Gate 3 should be rounded off with a retrospective to record learning from the sprint just gone.
Deploy
Once signed off by the customer its time to deploy the new software. It may only be deployed to a staging server if its part of a larger piece of work later to be joined by more functionality before finally going into production or this sprint on its own may be ready to go live now.
So based on the principles of card conversation confirmation its possible to get an agile lifecycle up and running without the need for reading lots of text books, getting certified or having the CEO's approval - its very straight forward to get started. Sure there are challenges in making it work and details to research and lots to learn about what can go wrong, but the most important bit its to get started now.
CardConversationConfirmation.com only covers the recording of the requirements data at the heart of this - however there are plans to introduce workflow in stages in subsequent releases of the software.
In part 4 I'll consider some key performance indicators (KPIs) that can be taken to demonstrate the benefits and measure progress and success. And, in part 5 we'll take a look at how this can fit into any governance system so long as it interfaces with it in the right way.