I am currently on a team that uses the agile process. We use VersionOne for sprint tracking, and TFS and HP-ALM for bugs. Here is my experience.
User Stories – Pre-sprint
The Functional and UX team writes “stories” that contain “user acceptance criteria” which explain in detail what is needed from a certain process. They tend to write things out like this:
1. The content manager needs to be able to add and control the order of ‘featured posts’
2. When choosing featured posts, the content manager needs to choose the order in which to display the posts
3. The choices the content manager will have are: date, alpha-numeric and most popular
…and so on.
The developers and scrum master meet in a room to read the user stories aloud, discuss complexity and issues, and try to answer any questions they may have.
Developers and specialists then proclaim a point to estimate the complexity that it may take to complete their tasks. The agile point system uses the concept of “relative sizing.” Where most estimates will be at the lower end of the Fibonacci series: 1, 2, 3, 5, 8, 13, 21 and so on. The goal is to group things of similar overall difficulty rather than a precise estimate.
- Complexity is the “stuff we have to figure out.” We know we can solve the problem, and we probably have a decent feel for how we’ll approach it, but we still have to figure it out.
- Effort is the amount of stuff that needs done.
- Doubt is about the stuff we don’t actually know if it can be done. Something that would cause you to spin your wheels for a while before you figure out if you can actually do the work.
Here developers and testers offer to do and test the work.
Developers then go to VersionOne and create tasks. Testers write testing parameters and process. This is where I will read the story over again, and really focus, imagine and write down every part of what I have to do. Here is where you make an hourly estimate.
The collection of all stories and tasks for the entire sprint.
A short 15 minute meeting where the entire team reports to the scrum master and discusses day-to-day issues and ‘blockers’ if there are any. The conversation goes like this:
- What have they achieved since the last meeting? (yesterday)
- What will they achieve before the next meeting? (tomorrow)
- Is anything holding up their progress? (impediments)
The measure of the amount of work a team can tackle during a single sprint and is the key metric in scrum. Velocity is calculated at the end of the sprint by totaling the Points for all fully completed user story.
When someone (e.g. John’s code is not deployed) or something (e.g. the ui is unreadable or program crashes) is stopping you from progressing further.
As you work, you can ‘burn down’ hours on your tasks. It is similar to a timecard process.
Once a week (or more) our department manager requests demos on stories so he can see the progress. It often contains positive feedback as well as constructive criticism. It also helps in getting a grooming session escalated since he holds more power than the developers. (This is not part of the agile process.)
Along the way, you may find the task is completely off track, more difficult than expected or impossible to complete as expected and needs to be looked at again by the functional UX team. The scrum master needs to address the stakeholders as quickly as possible and if they agree that their initial requirements were incorrect, they can start a grooming process that allows them to change the requirements.
At the end of the sprint, the entire team once again gathers to discuss how this sprint went and present ideas on how we can improve for the next one.
Hardening and Refactoring
A time between sprints allotted to going back and looking over the work you’ve done and making it better. We all know that when that sprint deadline is looming you may take some short cuts, or not spend as much time on optimization as you would have liked – this is the time to do it.