I’ve stumbled upon an interesting statement that project management frameworks and methodologies were made no to make the development faster, but to prevent the chaos while implementing a given project.
At Codetain, we mainly use Scrum to get things done. What is Scrum and how is it possible we work in sprints, but hate running?
Let me explain…
Scrum & Sprint
Within Scrum - an agile process framework in software engineering and web and mobile development - a team tackles the chaos by means of short development iterations called sprints.
The key assumption of Scrum (and sprints) is delivering complex work in small steps. Interesting fact - Scrum, tailored with software development in mind only, is now getting popular in other fields, as well.
Sprint: How Does It Work?
The iterative work process that Scrum is, consists of rather tight, cyclical deadlines which determine the progress of development. Usually, Sprints take one or two weeks, sometimes even a month - a specific amount of time is determined by a project.
During each sprint, a certain portion of software should be delivered. Software development in Scrum is generally focused on sprints - teams are working according to the sprint timelines, future work is planned and assigned to particular numbers of sprints (pretty useful when you’re about to point something out to your colleague; nah-ah, you were supposed to deliver that in the sprint number 4, dude, and which one do we have now?), etc.
How to plan a proper sprint?
Sprints might be longer, or shorter; they might involve few people or a huge teams, but there are always some points that need to be planned before the sprint will start! And that is:
- Capacity: Teams need to determine what their capacity in the next sprint is going to be. There are several approaches here - one of them is to choose and refer to an adequate number from a few sprints before and keeping doing the same each sprint.
Another one is to have a static number of points/developer days per each sprint, which are modified according to people’s vacation or some bank holidays. One thing is certain - different sprints would have the different numbers in capacity, since the live brings changes. - Sprint goals: Every sprint should have a clear goal - simple! However, the goals should be transparent for the stakeholders. When the sprint ends, there should always be a meeting called Sprint Review (more about it in one of the following articles about the Scrum), where development team present their results of the sprint.
It’s important to be able to show something tangible. Obviously, all goals should be delivered within the sprint. It’s hard to say whether the goals determine the sprint scope or the other way around. The key is to plan it properly, make is possible to be developed within the sprint, and include all the necessary tickets required by the particular goal! - Determined scope: If we know how much capacity we have in the sprint and what the main goals are, we can start to plan and assign the tickets to do during the sprint. This is usually set up during planning (another significant meeting within Scrum—will be described soon).
Development team is deciding which of the tickets will be tackled within the upcoming sprint. Remember to choose wisely - the scope should not change during the sprint.
Once we know how much resources we have in the sprint, the scope is determined, and we are sure that the goals can be fulfilled, we can start the sprint! The next part is to keep sprint on the track and deliver what was promised.
Hopefully, the intro gave you a clear insight on the framework. I’m already preparing myself to develop the topic in my next articles!
In case you feel it was too much information and way too many weirdly sounding words, don’t hesitate to get in touch with us. We’ll be happy to present to you how we work personally.
You can write to us [hello@codetain.com] or give us a call [+48 664 168 883] anytime and schedule an online meeting.