Back to List

Taking on Too Much Work in a Sprint (Agile Transformation Pain Point #13)

Rachael Wilterdink Rachael Wilterdink  |  
Dec 06, 2018
Some teams are super ambitious, and they just think they can climb a whole mountain in a single Sprint, but the whole goal with agile is to maintain a sustainable pace.

Take on only what you really think you can get done within your Sprint. Don't overestimate your velocity, and don't look at your history and rest on your laurels. Look at what you have available for your capacity, your skills as a team, and be realistic. Just keep it real.
taking on too much work

Carrying over work is demoralizing

What really helps a lot of teams is to focus on meeting their Sprint goals. I can't tell you how demoralizing it is for a team to take on a pile of work, and then to not be able to complete more than 50% and to have to carry that over into the next Sprint…and then carry it over again and again. You don’t want the team to experience this because they're going to feel like failures.

Be realistic

You want to make sure you pick enough things you think you can realistically get done, and then get them done. If you have time left over, there's nothing to stop you from looking ahead and asking the Product Owner if there's something else that's ready that you can pull in to your current Sprint (so long as you can get it done within that Sprint). Keep it real and keep it sustainable. You don't want people working crazy hours to try to get stuff done. That is really something you want to avoid, if possible.

Get the free eBook

This is the thirteenth of 20 blogs on 20 Agile Transformation Pain Points (and how to avoid or manage them). To read them all right now, download our free eBook.
agile transformation pain points ebook


Love our Blogs?

Sign up to get notified of new Skyline posts.


Related Content

Blog Article
Pre-assigning Work to Team Members (Agile Transformation Pain Point #14)
Rachael WilterdinkRachael Wilterdink  |  
Dec 13, 2018
This pain point is something you definitely don’t want to do. Agile and Scrum teams are meant to be self-organizing. They should volunteer to pick up assignments, not be assigned. Development team members are volunteering to do stories, and they might want to learn something new &ndash...
Blog Article
Not Having a Definition of "Done" or "Ready" (Agile Transformation Pain Point #12)
Rachael WilterdinkRachael Wilterdink  |  
Nov 29, 2018
Most people who are familiar with agile are familiar with the concept of definition of Done. This is something that the team should create when they are first formed, and they should continually be inspecting and adapting that at each of their retrospectives. They can update that definition of...
Blog Article
Diagramming & Modelling Tips for Business Analysts
Kurt WondraKurt Wondra  |  
Nov 20, 2018
Among the many responsibilities of Business Analysts, including Backlog Management and Communicating and Collaborating with our teams, the skill of diagramming and modelling is one which seems to be more taboo than mainstream. Have you ever wondered why that is?   One observation I&rsquo...
Blog Article
Forgetting to Have the "Conversation" (Agile Transformation Pain Point #11)
Rachael WilterdinkRachael Wilterdink  |  
Nov 15, 2018
You may have heard the three C's of agile: the card, the conversation, and the confirmation. Many people will have the card: they'll write the story, but they'll forget about the other parts. They'll just write it in a silo and not get any feedback. They won’t actually...
Blog Article
Struggles with Story Writing (Agile Transformation Pain Point #10)
Rachael WilterdinkRachael Wilterdink  |  
Nov 08, 2018
Story Writing struggles are so common and impactful that we offer a half-day training workshop on it for organizations.   Avoid technical stories Many Product Owners don't have a lot of experience writing requirements, and if you're a BA like I am coming from a waterfall world...