The Loose Definition Of A "Sprint" For Newbies

Most development shops have some kind of sprint process in place as a part of their "agile" environment. Not every shop is as strict on what a "sprint" is as others are, so over the course of your career you will see this process handled differently. While some places might include more detail in their sprint methodology, these are the basic steps you can expect to see everywhere.

Define sprint tasks (weekly, monthly, or some other time frame)

This will usually involve some kind of kick off meeting at the beginning of a sprint. You'll meet with the business side and define user stories for the sprint. Then you'll move on to define tasks from the user stories with the development team. From there, you'll usually assign time estimates, priorities, and assign tasks to developers.

The common length of a sprint is one week, but it could be different depending on what your team agrees on. Each sprint will have a progress meeting and after that you should have everything you need to get through the sprint. This is the time to ask questions and voice any concerns you have. If you have a good kick-off, then you should have very few questions to ask the business side as you get into the tasks.

Discuss progress bi-weekly

Some places do a daily stand up just to check on how things are progressing, but at a minimum it should be happening twice a week. It's important to make sure that everyone is on track to finish the sprint on time. That means giving people the help they need and working with them to get through tasks. If the place you work doesn't do something like this, you should definitely bring it up.

Having these quick meetings helps avoid that last minute scramble to get things done. Things happen and the team needs to know how they are going to handle them. Sometimes you need more information from the business side after you dig into the details and you need to give them enough time to respond. These meetings keep everyone on the same page about what's happening and keeps confusion down.

Deploy changes to QA/Dev environment for initial testing

Never deploy to production without testing. You don't need a QA team to do some initial testing. Before the end of the sprint you want to spend some time making sure your changes didn't break anything unexpectedly. It doesn't have to be anything extravagant, but if you can deploy the changes to the development environment you'll be able to do some decent testing.

This should only come when the tasks are complete or extremely close to being complete. That gives each developer on the team a chance to check that their code is working with the changes everyone else has made. Once you've finished your round of testing, then you can deploy the changes to the QA environment or let other testers know that the changes are available to test.

Review sprint tasks with business

Now that you've finished the sprint, it's time to review the items with the business side. This might include a small demo where you show them how the user stories have been implemented in the application. You'll go through and show them all of the changes you made and get their feedback.

What happens a lot of the time is that when you show them the updated application, they start to think about other things that can be done or they will have comments about the current changes. Regardless, you typically want to review the changes from this sprint with the business side before you deploy them to production.

Start planning the next sprint

After the review, the business side will probably have other things they want you to add or enhance. Some of those things might have come up in the review. Now that you are done with the current sprint, you can start working on the user stories for the next sprint. Now that you have been through this sprint and seen the application for the changes, you can start chiming in on the discussion. Don't be afraid to mention those places you saw that could be improved.

Deploy to prod

Once all of your changes have been tested and approved, you can confidently deploy them to the production environment. This is the moment you've been waiting for. Those changes you made will now be in front of users and it should make the application easier for them to use.

While they might not notice you moved that button inside of the modal instead of leaving it in a corner, you know it's there. Running load tests before you deploy to production could be a good idea if you expect the changes to drastically increase the load on your server resources.

Repeat

Congrats! You've made it through your first sprint. Now you get to do it again! The next time around will be easier and make more sense because you've got this one under your belt. Watch how you work during a sprint. Do you get stressed out or do you lose motivation? Or do you thrive in this kind of work flow?

I know this isn't the strict form of agile development and I'll tell you why. I've noticed a lot of places don't implement the agile methodology correctly and it leaves new developers confused on what's happening and where they are in the process. This is the most bare-bones way I've seen "agile" applied across different companies.

It's weird that it differs so much based on where you are when there's a definition for it… But I'm not the boss. 🤷‍♀️

Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding