Agile Planning and Estimating covers the activities involved in actually planning how the software being developed is going to be built, splitting up the development into manageable pieces and deciding a schedule for the release.  This part of my Agile development guide is based on the excellent book by Mike Cohn, Agile Estimating and Planning.

 

The following picture, taken from http://www.ebgconsulting.com/WorkshopsForAgileProjects.jpg, provides a clear overview of the activities completed during an agile project.

Scrum Plan

Release Planning

A release plan is the high level plan that is used to identify what needs to be completed and what time frame is required to complete enough before a releasable product is achieved.  The release plan is also the milestone that the team will be working towards over the course of the project and is used in determining overall project health.  With this plan the team has a clear goal of not only the project expectations, but also the expectations of the team; it provides overall goals.

A project must have objectives, this is most often financial but can be evaluated in a number of different ways.  I’ll write another post of producing a business case  to detail the steps that can be taken in evaluating and justifying a project.  Realistically, a project should deliver value in the most efficient way possible.  It may be the case that realising 80% of the total value in only 20% or 50% of the time is far more desireable.  Identifying what themes are required to deliver the desired outcomes is a critical part of this stage.

A project may be feature driven or time driven.  In the former case, the team will derive a time scale by summing the points for all of the selected stories, dividing by the teams velocity (To give the number of required iterations) and then multiplying by the length of the iterations.  This will generate the expected time to completion for the project.

For a time driven project, you should calculate the amount of available story points and then proceed add stories until the allotted time has been filled.  You can determine available story points by dividing the time frame by the iteration length (To give available iterations) and then multiplying by the velocity.

In order for a sponsor to identify what the objectives, constraints and expectations of a project are, the team should have estimated any themes or stories that may have a reasonable chance of being included in the release.

With the completion of these activities, the project will have a justified reason for undertaking it, expectations of various stakeholders and both time and cost estimates.

The final stage is to sketch out at least the first iteration, and possibly an additional 1 or 2.  Planning further than this can be wasted effort as when new knowledge about the product and project is obtained, future priorities will undoubtedly change.  It is often best to simply keep the next iteration planned and ready to go, the following 1 or 2 roughly planned and the remaining stories in the backlog.

Continue reading

All relevant stakeholders should be present at this meeting, including owner, Scrum master, clients and developers.  For a Scrum overview, please see Agile Overview.  This guide is heavily influenced by Mike Cohn’s Agile Planning and Estimation.

Choosing Themes

At project initiation, the team will meet in order to determine the themes and goals of the project.  In determining these themes, many factors will need to be considered.  These themes will also need to be estimated and prioritised so that the development team knows what to build.  These initial themes will form the general functional requirements for the project and will be expanded upon later on, when more knowledge is gathered about exactly what needs to be done.  The owner will determine the themes, but the developers will aid in this choice.  Developers can help this decision by indicating the risk level or dependencies of each theme.  These themes are often written on Index cards and should be considered at a high level of abstraction, such as:

  • As a user, I require the ability to add new cars so that I can manage my growing stock.
  • As a user, I should be able to buy items using a credit card so that I can process my order quickly and securely.
  • As a user, I want the software to record my high scores so that I can try and beat other scores.

Note that there is no technical specifics here, these are simply general, high level features that the user requires for the product.

Continue reading

Collaboration

Contrary to traditional management methods, an Agile approach considers the team to be a single cooperative unit.  Individuals are not scored on the amount of work completed, but the team is monitored as a whole.  This serves to improve team cohesiveness and ensure that anyone working on a project is dedicated to the success of a project through collaboration.  You are all in this together.

Product Owner

The product owner is the individual responsible for establishing a common vision.  This person is often the sponsor or customer of the project.  The owner must be the lead in identifying features (Stories) and prioritising the workload such that the highest value is being delivered.

Continue reading

Reason

When somebody wants to backup either the JIRA or Confluence onDemand databases.

Context

Atlassian onDemand does not currently have any features for automating a backup of either JIRA or Confluence.  To get around this we can trigger a backup from Atlassian and then automatically download the resulting file to a location of our choosing.  We can take this a step further by automating this processes with a cron job on Mac or Unix, or by using Windows Task Scheduler.

Disclaimer

These scripts were based on one given for Jira by Marlon Aguiar of Atlassian, the original can be found here.  Some minor modifications were made and a separate script for Confluence was created from the resulting code.

Continue reading

The following is an adaptation of content I wrote to help a new agile team.  It was meant to be a brief skim over the surface of estimation, rather than an exhaustive document.  It generally sticks to the classical agile approach, but has some additional techniques that I have found useful.  The information on which this is based is largely attributable to Mike Cohn, of Mountain Goat Software, perhaps my favourite technical author of all time and, for me, certainly one of the most readable.  I would love to hear peoples opinions on estimation, feel free to drop me a line with any tools and techniques that you use.


 

Story Points

It is very difficult to provide an off the cuff estimate for something unknown.  We may hazard a guess or try and compare it to something else of similar or relative size.  If asked to estimate the size of a mountain, it would be much easier to estimate it as double the size of another mountain than to specify a weight in kilograms.  There is also significant scientific evidence to support the hypothesis than humans are much better at estimating relatively than absolutely.

Story points are way of estimating effort to complete a feature that decouples that tie to specific units of measurement, such as time.  By estimating effort in relation to other estimates, we can derive a value for time.  Because we have estimated relatively, our final value for time is likely to be more accurate.

A story point is a unit independent measurement of effort required to complete something.  Features are measured in a number of story points.

A useful video by Mike Cohn discussing User Stories can be found here: http://www.youtube.com/watch?v=6q5-cVeNjCE.

Continue reading