This article is a brief introduction to the REpresentational State Transfer (REST) architecture. It is intended for aspiring/junior software developers and other technical professionals who would like to have a better understanding of REST.
Representational State Transfer is a system architectural style enabling the creation and utilization of web services. Services compatible with REST are referred to as “RESTful.” This is common among microservices, which allows for compatibility between multiple systems. It is a stateless protocol, meaning that requests and responses do not rely on prior messages.
One of the most common Agile methodologies in use is Scrum. It’s a really effective and flexible approach that focuses on building fully functional things within a short amount of time. It really shortens the feedback loop! I ended up adapting it for my own life management because of how well it meshes with my ADHD brain.
Scrum is a way of taking tasks and fitting them into a sprint, which is just an arbitrarily defined period of time – usually 2 weeks, but it could be shorter or longer.
During each sprint, there are a few rituals performed:
Standup or Huddle
Stand-ups or huddles are a daily meeting (ideally no longer than 15 minutes) for each team member to share updates with the rest of the team, generally describing:
What I did yesterday
What I plan on doing today
What, if anything, is blocking my progress or requires someone else’s participation
To understand backlog grooming, you need to understand the backlog. A backlog is basically a huge to-do list. It is often on a “Kanban” board which is comprised of 3-4 columns:
Product Backlog (Long Term)
Sprint Backlog (This Sprint)
Work In Progress
An example of Kanban columns used for backlog management
Backlog grooming involves looking at the product backlog (the long-term goals & projects) and writing down new tasks, (re-)defining existing tasks, and prioritizing them. This also involves estimating the amount of effort a given task might take using a point system. These points are used to determine both the effort of a task as well as a team’s working capacity/velocity (i.e., how much work can actually be completed in two weeks).
Sprint planning is a meeting where the next sprint’s action items are determined.
Sprint review involves bringing in the business team to review the completed work as a way of getting feedback on the development’s trajectory.
Sprint retro is a debriefing session. It involves looking at what the team did well, could do better, and actions to take moving forward.
As I mentioned before, I adopted Agile/Scrum to utilize for my own life management. This was especially useful to keep track of everything due when I went back to college a few years ago.
If you’d like to learn by doing, consider implementing a system similar to my own. Start by using Trello to create a Kanban board with the columns listed above. The Product Backlog column will be your long-term projects that need to be completed. The Sprint Backlog column will be tasks that you feel reasonably confident you can complete within the sprint. Try to keep no more than 3 tasks In Progress so you can stay focused.
To keep things simple, use a 1-week sprint (Sunday thru Saturday). Every Friday, sit down for Sprint Planning to consider the work you’ll accomplish next week, creating new cards as necessary to break down larger projects. On Saturday, you can have a quick combined Sprint Review and Sprint Retro to answer three questions before starting again on Sunday morning:
What did I do well?
What could I improve on?
What are the actions I need to take next sprint to improve?
There’s obviously a lot more to Scrum, but if you’re new to Agile I hope this helped to provide a solid overview.