I don’t know about you but I have always considered myself to be a very organized person, I mean I even arrange my clothes by occasion, color, and texture. Maybe that’s a bit extreme but it makes getting dressed very efficient. To say the least, when I first learned about Agile software development, it was right up my alley. Agile is an iterative approach to project management and software development that helps teams deliver greater value faster and with less mistakes. It basically involves breaking work down into smaller pieces with continuous evaluations.
Agile developers focus on sustainable development–not heroics. Sustainability is about good estimation, effective branching strategies for managing code, automated testing to protect quality, and continuous deployment to get fast feedback from users.
These ideas have been broken up into different frameworks, the two most popular being Scrum and Kanban. Learning about Agile can help you work more effectively as a team at your job or even just to plan out your own project. In this article, I’ll go over some fundamental concepts to get you started.
Stories
A story is typically the smallest defined piece of work. Stories can be expressed in many ways but a good pattern to use is “As a [person], I want to [action]”. An example might be, “as a reader, I want to share the post I just read to Twitter.”
Once you’ve figured out the title of your story, it’s important to describe the details and requirements of your story. This just means adding a more specific description of your story and a set of acceptance criteria that can help the developer gain context and understand exactly what is required to complete the story. A simple pattern to use for the criteria would be “Verify [requirement]”. For the example mentioned above, a criterion might be “verify when clicking the share button, a new tweet is created.”
Finally, stories usually have some point value representing the level of difficulty to complete that story. The points express how much effort a team of developers expect the story to be. The effort score can represent how difficult the story is or the amount of risk a particular story has. Typically, you’ll want to avoid pointing stories too high since that’s usually a sign that it could be split up into smaller stories.
Epics
While stories define a bite-sized piece of work, epics consist of multiple stories pieced together to represent a feature. For example, if an application requires the integration of authentication, an epic may be called simply “Authentication” and consist of stories like: “As a guest, I want to sign into the application with my email address” or “As an authenticated user, I want to change my password.”
Defining your stories in your epic gives you a sense of how much work something involves but it doesn’t address how long it would take. This is where sprints come in.
Sprints
Sprints are similar to epics in that they are a way to group work but sprints typically represent a period of time in which a chunk of work will be done.
A typical sprint may last two weeks and a velocity, or average amount of work to be completed, will be defined. The velocity is usually represented by a number of points that is a sum of the average velocity of each of the developers working on that sprint. It’s important to keep in mind that this point system can be different for each individual developer based on their own experience. While a task could take one developer an hour to complete, that same task may take a less experienced developer 3 hours. That being said, once you have a team average number of points, you can get a sense of how long it will take to complete a feature.
Conclusion
While every team works differently, having an understanding of Agile software development can be helpful for staying organized, maximizing productivity, and writing tested, iterative code. If you want to learn more, check out the following resources:
- Intro to Agile Video by Jira
- How to be an Agile Developer by Dan Radigan
Top comments (0)