Disclaimer: This document was created to help my team move into a more agile workflow. I am by no meams an Aglie expert or Scrum master. I simply tried to synthesize a bit of research. Any input would be extremly helpful! The language used below may directly reflect, but not directly quote, language used in other authors’ articles. Those articles are listed below!
- Exposition - What is Agile?
- Exploration - How It Can Help Us
- Excursion - How Do We Use It?
- Expletives - Drawbacks
- Eggs - Resources & More Info
Agile is a product development methodology that allows us to release software in increments, called sprints. These sprints can last a few weeks up to a few months, and allow us to respond to changing business needs as they happen, by requiring frequent feedback from stakeholders and users.
Developing our software components in this way will--
- Provide stakeholders with valuable productivity metrics and decision-making tools
- Provide users with an infrastructure for feature request and bug reporting
- Provide developers with clear and consistent feedback to increase productivity
Overall, an Agile work flow can help us decrease the cost of creating and maintaining software by increasing efficiency and communication in planning, execution, and delivery.
An Agile team will consist of three roles, the Scrum Master, the Product Owner, and the Agile Team.
A product owner can be the CEO, a board member, or otherwise someone who drives decision-making from a business perspective.
The Product Owner will--
- Define and prioritize requirements
- Determine the time line of a feature's release
- Take an active role in iterative planning
- Represent the voice of the software user (volunteers, operations, food donors, etc.)
- Define acceptance criteria (how do we know a feature is "done")
- Accept user stores that meet the definition of "done"
A scrum master is a scary phrase for the person, or persons, who often (but not always) drives decision-making from a technical perspective.
They are the technical manager who will--
- Liaises with all areas and departments
- Helps to remove blockers
- Ensure the technical team is on track
- Organizes meetings between the teams:
- Daily stand-ups
- Planning meetings
- Software demos
- Review sessions
- Retrospectives
The agile team is made up of the members of the development team; front-end developers, back-end developers, designers, etc. are all included in the agile team.
The team works in 1-week sprints. Each user story is planned into an sprint by using the prioritized backlog and the story's size. The team uses its capacity to determine how to make this plan.
We add user stories to our backlog at any time during an sprint, and then meet once a week to determine what goes in our next sprint. Before this sprint meeting can begin, the product owner must prioritize the stories in the backlog and clearly define acceptance criteria.
The following steps happen during the sprint planning meeting:
- The product owner describes the acceptance criteria of the highest priority item in the backlog
- The team describes the tasks required to complete the item
- The team estimates the time the story will take to complete
- A member is assigned the task based on their capacity
- The steps are repeated for each of the tasks in the sprint
- The team reflects on the distribution of work
A user story is a requirement presented by the product owner and refined by the team, together. A user story can take on two forms:
As a <user role>, I want to <functionality>, so that I can <business value>
In order to <business value>, as a <user role>, I want <functionality>
The goal of the user story is to concisely understand how business value can be gained by implementing certain functionality. This is one of the more powerful tools a product owner has to make clear business decisions.
- Bugs, which includes defects in the development phase
- Chores, or back-end action or development required
- Releases, used in a "go-live" scenario, like a product demo or beta release
During the sprint planning meeting, we meet to determine a story's point score. Each point usually refers to 8 hours. Any story of three more more points should usually be broken down into smaller stories.
A team's capacity is defined by how much an individual can commit, measured in hours. ex. if Barbra has a capacity of 30 hours in a sprint, we can reasonably assign to her two 2-point stories and a 1-point story.
During the meeting, we agree upon the functionality, behavior, and performance required by a feature in order for it to be accepted by the product owner. It defines "done".
During the sprint is where focused work gets done. Unless there is an emergency, an agile team should be able to expect minimal interruptions during a sprint.
Each day during a sprint, the technical team meets for roughly 15 minutes for a focused status update. Each member answers only the following questions:
- What did you do yesterday?
- What will you do today?
- What impediments or blockers are in your way?
The stand-up is a status update, not a discussion. Stakeholders and customers are encouraged to attend, but do not participate.
When stories are finished by the agile team, they're not considered complete until they have been accepted by the product owner.
The stages of completeness:
- Started - The story is currently being worked on
- Finished - The tasks to complete the funcationality have been completed
- Delivered - The functionality is now availble for the product owner to review
- Accepted - The story is now completed
- Rejected - The functionality does not meet the acceptance criteria
- Restart - The story is reintroduced into the current sprint after being rejected
It is important that product owners do not reject a story if they have changed their minds or if further functionality is needed. Instead, another story should be created and included in the next sprint.
At the end of each sprint cycle, the team meets to discuss their relative success during the last sprint. Each member of the team answers the following questions:
- What worked well for us?
- What did not work well?
- What can we do to improve our process going forward?
There is a barrier-to-entry for implementing Agile for the first time. This is due to the learning-curve as well as the perceived increase in work flow overhead. Suddenly we may find ourselves spending more time 1) writing tests, 2) sitting in meetings, and 3) waiting for feedback.
However, it is proven that this upfront cost increases productivity in the long-run by ensuring 1) that we have adequate test coverage, 2) that we are in fact working towards the correct goal, and 3) that the focus stays on providing value to the business and to the customers, not only to ourselves.
Before we can begin implementing Agile, the team must review our continuous integration, pull request review policies, and testing practices.
Hi, dropped in from Reddit. These are... well, certainly an interpretation of agility, and a starting point. One thing comes to mind, though: one of the highest values of agile is empiricism. As such, where you have defined your user stories through the fairly common formulations:
I have often found it more productive across the organisation phrase them in a way that acknowledges that there are many ways to achieve a business objective, and that you don't necessarily find the right way the first time off. As such, I tend towards the following formulation:
We believe that by DOING X we will move towards BUSINESS BENEFIT. We will know we are on the right track when METRIC reaches VALUE.
This tends to highlight that software is a continuous journey towards value, that this journey is fallible, and that the limitation on the way we pursue a direction is the quality of the direction itself. By encouraging business stakeholders to define metrics for success, we frequently avoid investing too much effort into a fruitless path, and are better able to gage whether we're getting closer to success.
On a separate note: I realise you're getting started with agility in general - what you have here... sure, it's a start, but some of the roles and definitions are a little shaky 😄. Since you seem to be taking a scrum-like approach, it might be good to review the scrum guide. Also, depending on the nature of your workflow, scrum might not be the best method for you... but it's usually a good way to start. My usual joke is that scrum is a problem-finding, rather than problem-solving framework. As you uncover more obstacles to agility, and resolve them, you may want to evolve your agile practice towards something better suited to the people and interactions in your organisation.