In Agile environment, some of the committed stories may not be completed at the end of the iteration. For example, in Scrum, the stories roll to the next sprint. There could be various reasons why some of the stories could not be achieved. Reasons include (not limited to) blockers, inefficiency, improper sync between team members, missing clarity, support from other teams, priority etc. A casual look on this can make someone think this is normal. But sprint success has a huge impact on the long term success of the team and the product.
Following are the some of the reasons why sprint success is important.
Morale : The team members self esteem actually gets higher when they achieve their goal. This breads confidence and help them to get better a their game, which can lead to more success.
Habit: Success breads happiness and more success. At the same time, failure breads failure. Also success/failure on one aspect of life can cause ripple effect on the rest of the life. We should be focused on success on every aspect of life so that it can bread in to itself.
Fig: Habit Loop
Fine reputation: More than any thing else, team will be very proud when they are able to successfully achieve the sprint goals consistently. Their reputation and respect around the company can actually go up and they will have to live up to that standard.
High standards: Team starts to set higher standard for themselves when they have high reputation. This helps them to get better at questioning, coding, testing, deploying and showcasing etc and improves their living standards in a holistic way.
Team bonding: When the team have a standard to live up to, they come together and get the things done, keeping aside the petty things. The goal becomes bigger than individuals and deliver thing as a team. This leads to higher team bonding and it reinforces their standards, reputation, habit and morale.
These are some of the main reasons why sprint success is important. When we focus on success, more positive things happen to the team and to the product that they work on.
There is enough motivation I have to write this article as the whole intention is to answer the questions which I have been asked multiple times pertaining to sprints I dealt with.
Some of which are listed below but not limited to
– How can we ensure sprint success?
– Should we do more or less?
– Why continuous improvement?
– How can I be successful? How can I grow faster?
– How to get better at estimation?
– Am I following the right set of processes?
– Is pairing good and how should we pair?
– Am I being heard? Should I challenge people? What if the team is very senior compare to me?
– The standup happens in the evening because of the offshore and onshore model? How to make it effective?
And the list is endless.
Let’s assume you are already in sprint cycle. One of the important questions is how do you provide an estimate for items which are already prioritized for sprint? The majority of newbies teams with limited exposure to agile struggle due to unknowns during mid-sprint which was not accounted for. The estimation might have given with many assumptions. The predictability is the biggest concern in most agile teams. One of the easiest ways is to pre-groom stories well in advance. Typically for two weeks sprint, I encourage the team to spend 10-15% of time daily during the second week of a sprint to get as many details as possible for next sprint stories, create tasks, identify dependencies, quick spikes to find out the feasibility.
The typical myth most people have that we should be adding only tasks having business values while it might be a look good factor for product owner but from a developer standpoint, this is something we should avoid. In addition to functional and non-functional requirements, a team should add testing, documentation, and everything that they would work on as a task. This given better clarity and sharing of work.
When you constantly spend time in grooming next week sprint story, you are very confident how much worth of work you can do it in next sprint when you get on to sprint planning as your estimates are good enough with confidence that what you are going to build. As this practice continues, there is a point which comes approx. in 3 to 4 sprints where the team doesn’t even pick a work which is not clear.
In summary, when a team starts with sprint, during the planning meeting, everyone talks about stories and tasks (Tasking is done). The goal is to add/remove items might not have been considered and provide estimates. The commitment is made with lots of confidence. You can never avoid unknowns while the chances of getting it reduced significantly increases.
Just to prove above point, once I have enforced SRS (Software Requirement Specification) in agile where it must have to be created and approved before planning a day in order for that item to be considered for planning. The team productivity dropped for 30-40% in first two weeks to get settled with new process inception and spending time in creating a document while as the time passed, the team who was not confident in doing 35 story points, hitting close to 60+ story points. All that happens in less than 4 sprints. Worth it!! Isn’t it?
This approach is phenomenal when the team is co-located while teams which are not, it can be slightly modified. For instance, the team at location x can pre-groom few stories and location y does the same with another set of stories.
There is another interesting thing which I have seen in offshore and onshore are sharing the same stories. The challenge is what I work (assuming I am at offshore), I need to hand off to onshore and vice versa. For 6 day worth of story, I and my counterpart need to understand what other person has done. The wastage of time in handoff and further understanding work done by counterpart every day by both ends adds extra hours.
I have seen instances when a story which can be done in 6 days took more than 6 days because of the addition of another person. Sounds funny? Yes, it is. Even if in extremely positive scenarios, it would add 50% extra time. A lot of people think we can avoid dependency and everyone should know everything, while it is funnier that the horizon of learning is limited for an individual if you look at long term. I am not saying that we shouldn’t do that but we need to be wary of taking a right decision. For instance, if there is a production issue or a complicated story which we want more than one person to learn/work or a story must have to be completed in little lesser time. With these kinds of practices, trade-off is understood. Compromising productivity to achieve temporary priority is fine in this case.
When the team is aggressive, they pick more points and to make up that quality is being compromised. Or the team may not be able to do that, which is even worse as it demotivates the team. I always tell my all teams to start with less (less than they think they can really do it). Further, as we progress, keep on taking more and more. The constant improvement is really important.
As discussed earlier, the pre-grooming or creating SRS very much fix this issue.
In order to have your sprint successful below is what I think are very critical
– Trust each other in team
– Give focused hours. Core working hours are really important
– Celebrate every victory
– Appreciate your team members
– Provide feedback openly
– Fail faster
The “I” factor usually becomes a challenge in many sprint teams. I will pick the certain specific piece and create dependency or I am more competent, and I would do my own over working with a team. The moment you see people like this in your team, get that fixed or move those out of the team. They just create a nuisance and spoil team culture. This is just a myth for an individual as it’s very easy to replace anybody in agile. The only worry, I see here is spoiling team culture.
As an individual team member of team, the success of him/her is
Constantly learning, learning faster
I have seen less competent team while better at supporting and trusting each other ended up doing much better in terms of quality, quantity and achieving business goals compared to high experienced teams with team culture lacking. Agile is all about self-organizing teams which move up in ladder by helping each other to grow. It is so beautiful that everything is visible and individuals with “I” and “We” just do not grow. If you are not able to openly give feedback to your team member because you are scared, you would end up being just mediocre. I do less because sprint success is important and does it matter if I work just 2 hours a day because I am completed all the work I planned. Sounds familiar?
Another interesting observation what I have from some of the developers is if I don’t contribute it is anyway not visible because I can show I am pairing or stuck on complicated issues or whatever. It’s is a just wonderful myth. The agile gives so much of clarity that everything is visible.
When it comes to releasing software, I would say release as many times as you can. This would force you to think a need of having lots of tests. Again one of the common challenges is, most teams focus well on the unit test while they hardly create integration test. That is bigger killer in long run. A lot of great teams are given 20% to 30% time in a sprint just to refactor code, working on extra tests which are not there or working on nonfunctional requirements. The challenge is if it’s not planned, it doesn’t happen. The human psychology must have to be addressed. If I am given a work on Monday and I am expected to do this by Friday, I would do that on Friday even if I could have done that in 2 days. In addition to that when you have a task it has to be done.
How great self-organizing team you have, it is always good to add work in sprint board.
The fear is another cause of doing less or not doing RIGHT. Many times teams are afraid that they may not be able to complete the work hence they pick less and even though work gets completed in advance, they keep picking less. The extra time remaining is good for learning new stuff and working on tech debts. 1/2 day or one-day learning is decent for two weeks of sprint while for tech debt and other stuff, planning results better outcome. When the team trusts each other, they as the team always take credit for success and accountable for failures. It sounds better. Indeed it is. Agile encourage you to fail while with every failure you should learn and avoid repeating that mistake. When you are working on existing complicated product, and while working on the story you see there is an opportunity to fix existing bug or refactor some code, I would say you should do it. Or plan to do it ASAP.
If your team or PO is discouraging you from doing that, talk as a team. Your goal is not just to fix issue what customer reported while you should be constantly striving to make your product better. The priority can be discussed and trade off can be identified while If you don’t do it, it would never happen.
Let’s talk about scope creep. The scope creep is nothing but change of scope or change in requirements
If it’s in middle of sprint, there are only two ways to manage it
– Push it to next sprint
– Remove the same amount of work to pick new work (Do it only when it’s VERY important). Agile completely discourages it but when there is a prod issue or something similar to that sort pops in, you might have to take wise decision)
If it’s outside of sprint
Agile is excellent, it depends on the SOW you have signed. Primarily, you can take something out or you can add another sprint to your total number of sprint or whatever you have agreed on.
I personally don’t allow a team to pick work which comes during the middle of the sprint. It creates lots of confusion. Until and unless it is extremely important, you should not be picking it up. The extreme urgency like prod issue comes from customer etc. Many of the things can be planned by keeping some 10 to 20% of bandwidth to manage these support issues. If there is a huge work which would spoil the sprint, the best thing to do is to start a new sprint.
Another practice which I feel goes pretty well when you have offshore and onshore model, is to have quick sync meeting in morning. Typically standup happens in the evening which is nothing but post-mortem or status meeting who is attending that in evening. It doesn’t have the benefits of stand-up at all hence meeting in morning for such team adds lots of value.
The demo and showcase are very important, and I always prefer a practice of showing it to team and PO as and when it’s available. How great the requirement elicitation is, there are always things which get missed. I have seen teams doing Agile with waterfall model and I call that as “waterfall agile”. Most of the team members work on development for first 70% of days and in the end, the focus is on QA which is ridiculous. Ideally, you should work on development, testing, and showcase. If possible push that code to prod as soon as you can and don’t wait for the whole sprint to get completed. There is an exception to this is when you have bigger products and many customers are using it. This kind of scenarios you should be looking at a number of tests you have and what kind of dependencies to be addressed.
Agile is really very simple hence it doesn’t allow you to do too much tailoring, unlike waterfall method. Every process is simple but it has to be done diligently. You don’t work as individual while you work as a team.