A lot has been written about software development methodologies, which ones are good, which ones are bad and which ones are just plain ugly.
I guarantee that if you have been developing software for a while that at some point you will have encountered the waterfall model. The waterfall model was a fairly good model it defined the steps in the software development life cycle but it wasn’t very good at iterative development.
The waterfall model didn’t lend itself very well to changing requirements without a lot of pain which generally manifesting itself in specification alteration, agreeing changes with product owners, development and architectural design.
Other models started to appear which tried to address the shortcomings of the waterfall model; The V-shaped waterfall model was one of them, it tried to address the process boundaries in the requirements, testing and delivery phases of the project, but it was still unsatisfactory.
Along comes Agile. Agile provides a way to allow the project to flow and embrace change as it happens (and change WILL happen).
A lot of people think that using Agile is a way for developers to avoid writing specification, to avoid the rigors of quality control ultimately bringing chaos into the organisation. This assumption couldn’t be further from the truth.
There are a number of ‘flavors’ of Agile, the one that I will focus on is called Scrum. So what is Scrum. Put simply Scrum is a process where you divide up the work that needs to be performed into epics, stories and tasks. A scrum consists of ‘sprints’; a Sprint is just a period of time where the developers work on the tasks allocated with the aim of having all tasks / stories implemented by the end of the sprint.
We use a scrum board to help us manage the tasks so that we can visually see what state the project is in. At its most basic the scrum board will consist of the following columns:-
- To do
- In Progress
- In Test
Typically columns A and F wouldn’t be show but are implied. The backlog is the location for all the epics / stories / tasks before they are moved into the To do column.
Typically a sprint will last between two and four weeks ending in a sprint retrospective and a planning meeting.
During the retrospective meeting the team should reflect on the work that was done and assess how they think the sprint went; what went well, what didn’t go well and why, what have the team learnt, what problems occurred and how could they have been avoided.
During the last few days of the sprint the team members should be looking at the backlog of tasks / stories and assessing how long they think it will take to execute the tasks. When the planning meeting starts the team should look at the backlog and add the tasks that they are planning on delivering into the ‘To Do’ column of the scrum board.
Now I’ve given you a brief introduced you to the Scrum board lets take a look at Epics, Stories and Tasks which we will place onto our Scrum board.
An epic is a high level description of a requirement. You will probably have a business requirement for some functionality that needs to be added or a change request that needs to be implemented, each business requirement can be considered an epic. An epic can consist of one or more stories.
An example of an epic could be:-
‘Application’ X should be able to connect to server Y and request data Z every 60 seconds and write the response to a file
A story is a one aspect of an epic. A story describes what is needed at a slightly lower level. Using the epic example described earlier lets try and break this down into one or more stories. What do we have to consider when reading the epic;
- what protocol will be used to communicate with the server Y; will it be HTTP, HTTPS, UDP, TCP
- will the ‘Application’ be a standalone EXE or a windows service
- should the polling be configurable
- when we write the response to a file what security considerations do i need to think about; will we have write access to the location
- is the location that the response is written to configurable.
- is the request asynchronous or synchronous, what happens if the responses overlap if the one request takes a long time to complete
- should request be allowed to timeout
- is the server end-point configurable
I’m sure that you could break this down even more but lets take those and try and create some stories. For now we will assume that we have the answers we require to the questions above.
- The ‘application’ will be a windows service
- It will use the HTTP protocol
- The file location will be configurable
- The folder the file is written to will have write access for the network service account
- The polling time will be fixed at 60 seconds
- The server end-point will be configurable
As a service i want to create a HTTP connection to Server Y
As a service i want to connect to server Y every 60 seconds
As a service i want to store the response from server y in a file
As a service i want to be able to configure the server end-point post installation
… etc …
As you can see these try and describe the requirements but they are not complete. We will now break down these stories into tasks and this is where we need to actually separate the tasks into:
- nice to have
- wish list
‘Basic’ tasks are the ones that we will implement in order to get the minimum functionality in place.
‘Advanced’ tasks are the ones that build on the ‘basic’ tasks and introduce more functionality
‘Nice to have’ tasks are the ones that we will implement if all advanced tasks are complete
‘Wish List’ tasks are the ‘Bells and Whistles’ tasks that will make the project shine
Lets take Story 1 and see what tasks we can break this down into.
As a service i want to create a HTTP connection to Server Y
– Connect to server Y using a synchronous web reference
– When a connection cannot be created the service should throw an exception
– Connect to server Y using an asynchronous web reference
– When a connection cannot be created the service should write the exception to a log file
Nice to have
– When an exception is thrown details should be written to the system event log
– The server end-point should be configurable
– Allow the web reference to be injected using IOC so it can be reused by other classes and modules
When we create our tasks we wouldn’t include all of the tasks on our scrum board, we would only initially add the ‘Basic’ tasks and associated stories. The idea being that we should move the tasks from the left hand side of the board to the right hand side of the board during a single sprint; implement a ‘straight-line’ solution that, when committed to source control would mean that we have a solution that builds and does the basics.
All the tasks on the board should have the same priority so any developer should be able to pick up any task and begin work. When you have a series of stories it makes sense to make someone a story ‘owner’, this means that they are responsible for:-
- Writing any supporting documentation
- Understanding the requirements
- Managing the implementation of the tasks between developers collaborating on the story
- Developer testing the story
- Making sure it passes any user acceptance tests that have been defined around the story
- Demonstrating the story at the end of the sprint.
The next article will look at:-
The enhancing the stories with ‘Advanced’ and ‘Nice to Have’ Tasks
Please check back soon 🙂