Questions about the end of a Sprint

What is the process when an engineer completes all their tickets (Story Points) a day or two before the Sprint ends?

To me, that is the first problem in your statement. The items in the Sprint Backlog are owned by all of the Developers.  A single person may have completed all of the tickets that they have chosen to work on but that does not mean all of their tickets are completed.  If there are any tickets in the Sprint Backlog that have not been completed, that individual still has work that is left to be done.

I coach teams that no one finishes the Sprint until the Sprint Retrospective has occurred.  Until that time, any work remaining is still theirs to help complete.  Could they help someone else?  Could they pair with someone to expand their knowledge of the code base?  If neither of those are true, then there is still a lot that the individual can do for the Scrum Team.  They could spend time refining items that are in the Product Backlog.  They could research some topic that the team has discussed so that they can pass that knowledge along to the rest of the team. They could create tickets in the Product Backlog that will let the team address technical debt.  

There are many ways that an individual can benefit the team without directly writing code. 

Option 3 basically lets a resource sit underutilized.

That statement is not always valid.  Does your organization promote a culture where people are able to learn and advance their knowledge in their chosen field?  If so, allowing that individual to learn new things is in line with the organizations idea of appropriate utilization.  It is also a benefit to the Scrum Team because it adds knowledge and capability to their makeup which in turn could help them be more productive. Remember that a engineer is not like a printer.  Printers can be considered underutilized if they sit idle for long periods of time.  But software engineers very rarely sit idle. They are usually doing something all the time.  The trick is for those individuals to learn what is beneficial to the rest of the their team/organization and do that over activities that are not going to benefit anyone.

I agree with Daniel but would add a couple of things.

The notion of assigning "tickets" to engineers is antithetical to the self-organizing and self-managing nature of Scrum Teams. No one should be assigning work to the Developers on a Scrum Team. The team should be pulling in work from the Product Backlog and then pulling the work through the workflow to a Done state. In a self-organizing and self-managing team, a professional would be able to focus on the team's commitment and find a way to make sure that the team is able to meet those commitments, primarily the Sprint Goal.

The concept of Slack is vitally important to an agile team. If everyone is expected to be busy working on things all the time, you have no opportunities to handle the unexpected. Agile is about responding to uncertainty and the unexpected that is bound to come up while going about the regular work. A focus on utilization and underutilization is contrary to having sufficient slack to respond when someone else needs help with work or some unexpected work comes up. Then, the team needs to worry about the cost of context switching and the costs of not doing certain things to make a decision about what to deliver.

What is the process when an engineer completes all their tickets (Story Points) a day or two before the Sprint ends?

Story points are a strange thing for an engineer to wish to complete. Why bother? I'd suggest that it's valuable work which ought to be completed. Story points are just a way for Developers to get their arms around how much of that work they can jointly take on.

Assume there are no small tickets (features or bugs) that can be assigned. Any ticket assigned would not be able to be completed.

Have the Developers met their commitments? Has their Sprint Goal been met and at least one Done, finished, and valuable increment been produced?

Both approaches 1 & 2 seem problematic for different reasons. Option 3 basically lets a resource sit underutilized.

If they've met their jointly agreed commitments those so-called "resources" can throw a party, go on holiday, start new work, or otherwise do pretty much whatever they want.

Perhaps it might be better to think of team members as creative professionals who pull work to them, inspecting and adapting their progress to a shared commitment, and not as "resources" to be "assigned" work at all.

The comments above are interesting and helpful. I have worked in software engineering at seven different companies using Scrum, from small startups to very large Fortune 500 companies. Not one of them came anywhere close to what you have described as to how Scrum and/or Sprints are to suppose to be run. The above sounds more like "theory" as oppose to what is actually done in the wild.

Try thinking of it the other way around. What happens in the wild is far too dependent on theory: waterfall, weird, and wacky. The advice given above dispenses with such theory in favour of empirical outcomes. That's how Scrum is supposed to run.

I have worked for a wide variety of companies also, large and small.  I have worked in some that used the methods provided so far with great success.  Those are the ones where the entire organization was willing to adapt to agile methods and saw the benefit in it.  I worked at one company where the entire company utilized the Scrum framework.  That included the C-staff who worked as a Scrum Team.  It can be done but only if the organization is willing to change to the empirical methods. 

Like you, I have also worked at companies that said they were using the Scrum framework but were not willing to change their hierarchical command-control methods.  In those cases, there was very little value seen and their versions of "scrum" were not according to the Scrum framework put forth in the Scrum Guide. They used terms like sprint, stand up, sprint review, retrospective, planning but they did not mean the same thing as what is described in the Scrum Guide. The way you have phrased your original question, it seems that you may be working at one of these organizations. As such, you should look internal to the company for the answer to your question.  The people on this forum will provide you  answers as they relate to the Scrum framework described in the Scrum Guide.  We all have opinions on the non-Scrum also. Personally, I usually prefer to keep those to myself in these forums. 

In this case, my advice is to go to your team and let them decide as a group how they would like to handle the situation you have asked about.  Even if your organization is not following the Scrum framework, it is still a good idea to involve the people doing the work in decisions on how to do that work.  It usually results in answers that they are more willing to accept and you may be surprised by their solution.

I appreciate everyone's ideas on what to do with the "downtime" after finishing up tickets at the end of the Sprint. Here is what I have seen in the wild:

1) It is impractical to help others finish their tickets nearly 100% of the time. Picking up small tickets that have not been started does happen.

2) Sometimes learning new technology or expanding knowledge is an option

3) Grooming has ALWAYS been a team effort, not sure why because it is often a huge waste of time for a majority of the team.

Thomas' comment about self-managing and self-organizing has never happened in my experience. The constant that I have seen is that Scrum is used to micromanage the software development process. Most managers lack trust in their developers and LOVE micro-managing them.

Although assigning tickets might be antithetical to Scrum, I have never been part of a situation where a Sprint starts and everyone grabs tickets from the backlog. In large projects, engineers often have specific areas of expertise so doesn't make sense to grab the next highest priority ticket. Also, every team I have been on assigns tickets to make sure each engineer has enough work for the Sprint, and the amount of work that can be completed in the Sprint.

Ian's comment about non-Scrum approaches ends in "waterfall, weird, and wacky" is something I often hear, which is the thinking that: "If is isn't Scrum, then it is Waterfall, and Waterfall is very bad." I agree that Waterfall is very bad. Although many think Iterative, Incremental Development (IID) grew out of Agile/Scrum, it was used more frequently in the 1970's on until today, IID dates as far back as 1930s. In fact, IID predates Waterfall as a software development process. I was on a huge project in the late 1990s and it used IID very successfully without Scrum. Contrary to popular belief, a lot of great software was created before Scrum and Agile become a thing.

I understand many of the comments above is how Scrum is suppose to be performed. The reality for myself and every engineer I have spoken with on this subject, is that few organizations are coming anywhere close to doing Scrum correctly. Is poorly implemented Scrum better than not using Scrum?

Scrum is not the only way to be agile.  I have been in software development since the mid-1980s.  Like you, I have worked on many successful products/projects that weren't exactly waterfall but weren't what today is known as Agile.  (BTW, Agile is a marketing term used by people that tried to commercialize the Manifesto for agile software development.  That manifesto wasn't trying to establish a process or methodology. It was trying to convey some principles that would help people be more adept at reacting to changes, i.e. showing more agility.) 

I realize that you may never have been in a situation where the Scrum framework was used as it is described.  But others, such as me, have and it can be very effective and liberating.  Remember that Scrum is a framework not a process.  It provides guides to be efficient using empirical ideals.  The actual processes that are used by organizations are entirely up to the organization to choose.  That is why there are so many organizations that claim they use Scrum but in effect, they are using Scrum terms but not in the way that the Scrum Guide explains them.  I have heard people say "Scrum is easy to understand but difficult to use".  I actually believe it is difficult to understand and near impossible to use.  Not because of the actual words used in the Scrum Guide but because of the way that the world has evolved based upon militarian command-control methods.  That is what you describe as being your experience.  I doubt that anyone reading or contributing to these forums can say that they have not experienced them also.

You say that managers like to assign work to their employees.  Currently, I am a Software Engineering Manager. In fact, I have had such titles for the last 11 years.  In all of that time, I have never once felt that I needed to assign work to any of the people that reported directly to me.  The majority of my peer managers have felt the same way.  By allowing people to choose their own work, they have a stronger desire to complete the work with quality than when they are told to do something.  I may have been lucky with the places I have worked but they include some U.S. based federally regulated industries so this is not something that can't be done.  It is something that people choose to do. 

Is poorly implemented Scrum better than not using Scrum?

There is no such thing as poorly implemented Scrum.  According to the Scrum Guide:

Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Poorly implemented Scrum can actually be detrimental because it is not always clear what rules are in place.  Many places say that they use Scrum so that they can change the rules of engagement as they go along.  That is not the intent of Scrum or any agile practices.  The intent is to allow organizations to adapt to changes in requirements, economy, law, environment, etc as they occur.  Sometimes that does mean the rules of engagement may change, but those are done based upon empirical evidence that something needs to change and not because of someone's desire to change. 

I hope you get the chance to experience a true agile organization at some point in your career.

I understand many of the comments above is how Scrum is suppose to be performed. The reality for myself and every engineer I have spoken with on this subject, is that few organizations are coming anywhere close to doing Scrum correctly.

Everytime I read something like that, Larman's Laws pop up in my mind :-(

https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior

Daniel W., I am aware the differences between Scrum and Agile and agree that Agile has been turned into a money making enterprise. This is why one of my favorite videos is Dave Thomas' "Agile is Dead" talk to GOTO - 2015.

I have always said that a heavy process like Scrum is for engineers that are incapable of communicating and "can't get sh*t done." I favor a process of milestones that are feature driven. I all too often see tickets that are too small and can make it hard to tackle the larger problem with a good architecture and design. Almost like asking a mechanic to build an engine without ever letting them see the big picture, you just start handing them parts and expect an engine to somehow appear. Give me a feature, but don't make me break it down into little pieces. Most of the time many different parts need to be build at the same time.

When I wrote the printing system for the Firefox browser, it was basically one ticket: "Make print work in the browser" I didn't need a ticket for printing in IFrames, or a ticket for handling CSS, etc etc etc. I didn't need Sprints or stand ups. I just needed people to leave me alone and let me get the work done. :)

I have been fortunate that for the majority of my career, to work with excellent experienced engineers that didn't need to be managed or watched. Which is why I find this entire fascination with Scrum / Agile so frustrating.

Rod, it doesn't sound like you are either a fan of Scrum or currently practicing Scrum where you work.   Which begs the following questions:



"Why is your organization trying to practice Scrum?"

"What problem(s) is/are your organization trying to solve through the Scrum framework?"

Timothy B. You are correct I am not a fan of Scrum, but the software development industry IS a fan of Scrum. So I must exist within it's confines until it dies. I think the majority of the folks teaching, coaching, or doing Scrum successfully would be shocked at how large the percentage is of companies that say they are doing Scrum and are failing at it, at least in terms of doing it correctly.

That is why I asked the question above "Is poorly implemented Scrum better than not using Scrum?" From what I have seen (and see), the only real qualifications for doing Scrum are saying these words: Sprints, Tickets, Stand ups and Grooming. Although I have been at companies "doing Scrum" that don't even do grooming in any official capacity.

My guess is a lot of companies say they are doing Scrum because that's what everyone else is doing or say they are doing. Plus, they probably wouldn't know how to implement a non-Scrum process, so it is better to do Scrum-lite than tell the VP of Engineering they don't really have a process that will enable them to deliver consistent results. Most companies have never delivered value to their customers in any consistent way. I can easily say that because around 70% of software projects fail, and having an ineffective software process is only one of the many reasons. (I am not saying that doing Scrum correctly is ineffective)

Scrum is a means of establishing empiricism under complex conditions of high uncertainty. That's what the framework is for.

My advice is to think less about Scrum as something that is implemented for its own sake, and more about complexity and the need for empirical process control to be established and maintained. Scrum is a means to that end. If you genuinely don't need that, then you don't need Scrum.

I think the majority of the folks teaching, coaching, or doing Scrum successfully would be shocked at how large the percentage is of companies that say they are doing Scrum and are failing at it, at least in terms of doing it correctly.

No, none of us would be shocked because we already know.  Trust me on that one.  :)  

Maybe if you stepped back for a minute and looked at Scrum like it really is. It is not a methodology or a process.  It is a framework.  You should be familiar with frameworks as a developer.  They do not specify how you do things, they provide guidelines and boundaries to help you do things.  Scrum is not the right solution for every organization.  In fact, it isn't the right solution for every group within a single organization.  Scrum works well in situations where there are more unknowns than knowns.  It helps "find the way" to the solution by encouraging small incremental steps towards a goal that is then inspected and adaptations are made.  Thus the goal can change as you go based upon new information and discovery.  Your example of creating the printing system for Firefox fits into the more knowns than unknowns in my opinion.  Creating a brand new application fits more into the more unknowns than knowns to me.  That is because the longer it takes to get a feature created, the harder it is to know how it will be used and what it actually needs to do.  In the "old days" taking six months to deliver a feature was ok because the environment, economy, technology didn't change very fast.  But with the pace of today's world, six months could be the difference between success and failure of an entire company. 

I recommend that you step back from Scrum because like you said, it is usually not done as described in the Scrum Guide.  Go back to the Manifesto for agile software delivery which started all of this. Decide if you agree with the values and principles that are listed there.  If you do, then look for ways to help the teams and organization you work with to also see that value.  One of these days, Scrum may start to make more sense to you.  

And I can't mention the manifesto without saying this.  Most of the signatories have said that they wished they had not written it.  Because it failed to do the thing that they wanted.  It became a commercialized ideal instead of a ideology.  But the values and principles are still sound today.  

You may feel like we are ganging up on you.  But, again, trust me when I say that we completely understand how you feel.  I can't speak for everyone that has commented but I appreciate that you are trying to understand and hope that I can help.  Look me up on LinkedIn if you want to do some 1-on-1 discussions or just keep going here so that you can get more varied discussion.  It is people like you that keep all of us encouraged that we aren't completely wasting our time.