Chapter 9: Agile Concepts
Sprints
A sprint is basically a fixed period of time in which a set of work gets done. In Agile we call this fixed period of time a timebox or sprint and the set of work "user stories." Don't worry we'll go over the concept of user stories soon.
Sprints can last between 1–4 weeks, but they typically last 2 weeks. Just keep in mind this varies from team to team and there's no right or wrong answer on that.
Some Agile teams have Sprints that last 1 week, others have Sprints that last 2 weeks or 3 whilst others prefer working with 4 week Sprints. The key point here being that Sprints are fixed periods of time, so they shouldn't vary over time but should remain constant at all times.
Although, Agile teams can decide to alter their Sprint duration if they consider it would work best for them after going through a couple of Sprints.
So Sprints end up being like repetitive cycles in which the Agile team delivers a set of user stories.
User Stories
User stories are derived from requirements, but they're more like tasks. Some people argue that they're not really tasks but more like value adding pieces of work which can result from one or more tasks. In practice and in projects, you'll see Agile teams treating user stories like tasks, since it allows them to organize all the work they need to get done in their sprints.
User stories, like the name implies, tell a story, so they have a particular structure which goes like this: As a <role> I need to <what> so that <why>
For example, As a Developer I need to create an option to register with Facebook so that end users don't have to create accounts from scratch.
In practice, writing user stories using the structure above becomes a bit redundant and repetitive, so you might see Agile teams, writing user stories as one liners of what needs to get done. In the example above, it would be like this: Create an option to register with Facebook
So it's kind of like a summarized version. It starts with a verb and clearly describes what needs to get done. The team itself already knows why they're doing it, so they don't add it to the user story description. Having said that, some Agile teams like to follow things by the book and will write user stories as originally intended. It's up to you really whether you want to adopt the theoretical or practical approach.
User stories should include story points (which we'll explain later), acceptance criteria (when they can be considered done which is just a quality measure) and they should be assigned to someone in the Agile team. They should also follow the SMART principle. That is, user stories should be Specific, Measurable, Attainable, Realistic and Time bound.
User stories are generally written on post it notes or on digital cards in Agile tools such as Jira or Trello (we'll cover those later)
Story Points
Story points are basically a measure of complexity assigned to a user story. As in how complex it is, which of course relates to effort and time for completion.
Story points are used for Sprint planning, since they allow the team to agree on how much they will commit to deliver in each Sprint (how many user stories and how many story points)
I recommend the scale of 1, 3 and 5 for story points because like Agile it's simple, easy to use and easy to understand. You basically assign 1 story point to low complexity user stories, 3 story points to medium complexity user stories and 5 to high complexity user stories.
Remember, you shouldn't over think when assigning story points to user stories, keep it simple, the Agile Way! Discuss it with your team and come to a consensus, just keep in mind it's an estimate. So don't spend too much time on that and don't try to reach perfection.
You should know there are other scales out there which you can use to assign story points, and different Agile teams use different scales (e.g. the Fibonacci sequence: https://en.wikipedia.org/wiki/Fibonacci_number) and estimating methods, but like I said before I recommend the simple approach of using 1, 3 and 5. It's simple, easy to use, easy to apply and easy to understand.
Epics
Epics are basically user stories that are so big they can't be completed in a Sprint. In Agile, we refer to these user stories as Epics.
When Epics are identified, the Agile team then reflects into how they can be broken down into smaller user stories which can be completed within a Sprint.
Product Backlog
The Product Backlog is basically a list of all the user stories required to complete the product, service or project.
It's also a living document, not a static set once and forget type of document.
Sprint Backlog
The Sprint Backlog is a subset of the Product Backlog, and basically refers to the group of user stories that the team has selected to complete in a particular Sprint. So each Sprint will have its own backlog.
Like with the Product Backlog, the Sprint Backlog is also a list of user stories, but not all of them, only the ones related to a particular Sprint.
Minimum Viable Product (MVP)
The Minimum Viable Product or MVP is one of the most important Agile Concepts. Essentially it refers to the minimum amount of work the Agile team needs to deliver to meet the key business requirements.
So often you'll hear Agile teams say "this is our MVP" and when they say that, they are making clear to other people what they are going to deliver when they complete the project. A Product or Service with these characteristics, that will do this, etc. which implicitly also explains what the team won't complete or deliver. At least not in their first iteration or version of the product or service.
The importance of the MVP comes from some of the core Agile principles, simplicity and iterative development. Which basically means don't build a rocket if all you need is a paper plane. Or better yet, if you do need a rocket, start with a paper plane and then continually improve that until you deliver a rocket. This allows for quick delivery and for customers to start using the end product or service faster. Not having to wait months or years for completion like they do in traditional Project Management (the Waterfall approach).