Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 23, 2014
arrowPress Releases
October 23, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Using Scrum in “Real World” Game Production
by Harvard Bonin on 04/19/14 12:34:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


Scrum.  Even the name is annoying.  It’s just so…fancy.  Short for “scrummage”, it originally came from the term used in rugby to restart play, sort of like a huddle in football.   It was first introduced in 1986 by Ikujiro Nonaka and Hirotaka Takeuchi as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal"(1). Nowadays there are certifications offered by the Scrum Alliance and and there are very stringent rules surrounding its use in development. You can even become a “ScrumMaster.”  Maybe that’s my exact problem with Scrum.  It’s too rigid for my tastes.  I find it interesting that a methodology that espouses being agile is itself full of hard and fast rules.  It can really turn off a team.  Scrum can also be viewed as slightly religious and its practitioners zealots for the cause.   Also, Scrum adopters are often only trained in Scrum so they don’t know that there are perfectly good traditional project management tools available as well.  Worst of all, when implemented poorly Scrum will mismanage titles and remove any hope of team adoption.


I still really like it…or at least the spirit of it.  There’s a term in the field used for what I’ll describe shortly called “ScrumBut.”  As in “it’s Scrum…but not all the time.”  I am a believer that the internal team producer or project manager must be well versed in lots of methodologies and tactics in order to apply the right tools to the specific problem.  Traditional project management often relies on very well-known products and is generally applied to production lines such as creating a car or house.  As we all know, software development is forever in flux and Agile methods (Scrum, in this case) were specifically created to manage these continuous changes.  In this article I’ll discuss my own experiences and how I think Scrum in particular can be best applied to game development.

This article assumes the reader has at least a basic knowledge of Scrum and will not go into detailed definitions of the method.  I’m also assuming the producer works on an internal studio team. External production and publishing is a topic for a different day.


The first thing a producer needs to do is get trained.  As you’ll see in my last article this is a big emphasis for me.  This training should not cover Scrum alone.  It needs to include a variety of Agile methods along with traditional project management approaches.  There are lots of books available that outline Scrum.  A couple of my favorites are Essential Scrum by Kenneth Rubin and Succeeding with Agile: Software Development using Scrum by Mike Cohn.  Both give a good overview of how to apply it in practice and can easily be found on Amazon.  There are also lots of workshops to attend, often run by the authors of the many books.  Clinton Keith has a pretty effective one, I’m told.  This information can be readily found online but these provide insight to only one slice of the pie.  Scrum is categorized as an Agile Methodology and its only one in an array of these methods such as Prince2, Feature Driven Development, Dynamic Systems Development Method, Crystal, Extreme Programming, etc.  To top it all off there’s a whole other category called Traditional Project Management and there are a ton of books, classes and certifications as well.  The Project Management Institute (PMI) is the organization that leads and upholds these standards.  It offers the Project Management Professional certification (PMP) for project managers and producers as well as program, portfolio, Agile and other certifications. I recommend pursuit of these too.   A responsible and informed producer must have a knowledge base that includes all the topics noted above so that he or she can pick and choose the right approach to game development.  Without this wide knowledge base the producer will be limited to only a few weapons to attack project management problems. 

The reality is that there isn’t a “one size fits all” solution to the many challenges that arise in game development.  While Scrum alone may work pretty well early on when the team is small, the backlog is fairly known, the development is very iterative and in discovery mode requiring a lot of collaboration, it may not work very well within a large team in Execution Phase (i.e. full production).  In fact, it may slow things down.  The full development team should never be in concept and discovery mode within the execution phase.  The full team usually has a more expensive burn rate and if core design decisions have not been made before their assignment the team (which usually has the most members in this Execution phase) will bleed money and lower the chances of success.  That is not to say creativity cannot occur during full production for all team members.  An easy metaphor I’ve used is “the execution team sculpts the statue, the concept team creates the clay.”   Traditional waterfall approaches generally work best for full production. 


Scrum is actually just one part of the Agile family of methods.  The Agile Manifesto was created in 2001 as a result of the collaboration of some veteran software developers (2)…

            Individuals and interactions over processes and tools

            Working software over comprehensive documentation

            Customer collaboration over contract negotiation

            Responding to change over following a plan

These points were created in response to traditional project methods that were mostly ineffective in the forever changing world of software development.  Building software is not the same as building a house.  The blueprints for a house generally won’t change drastically.  In software development the design can change daily.  They also created some guiding principles which are:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity--the art of maximizing the amount of work not done--is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

As a producer I generally agree with the sentiment of each.  Sure, they’re idyllic but we all need to aspire to some development philosophy and generally I like these.  However, there’s one that I fundamentally disagree with.  Can you guess which one?  If you guessed #2 you’d be correct.  On its face it seems that the creators didn’t consider the reality of business requirements very much, at least in game development.  Traditional project management will teach you that changes, especially big ones late in the project lifecycle are also the most expensive.  Furthermore, the very nature of Agile development would by definition negate the need for late changes due to its iterative process.  In other words, the team should have already discovered what it would discover much earlier in the project lifecycle. To me it’s unrealistic and not founded in business reality.

So why is it necessary to know the basics of Agile to operate in a Scrum environment?  Simple.  If you don’t you’ll implement Scrum blindly without fully understanding why it is the way it is.  You’ll fall into the Maslow’s Hammer trap AKA “When you only have a hammer everything looks like a nail.”


There are many usable tools within Scrum.  I have found that blind application of them without fully understanding their purpose and how they work is misguided.  Here are some ways I’ve tried to apply them in, what I consider to be, a responsible way.

Assigned Roles:  In Scrum there are a few key roles like “Product Owner” (Decider of the backlog and priority), ScrumMaster (organizer and Scrum traffic cop) and Team (content contributors).  Whatever your terminology I am a big believer in assigning clear roles on the team, communicating them and then requiring those people to act accordingly. Scrum or no Scrum this is important.  If you’re the Product Owner then you have to be the one prioritizing the back log and making decisions so the team can move forward.  If you’re the ScrumMaster, make sure that you’re holding and enforcing the Scrum rules of work.  In other words, if you are going to use Scrum make sure you’re at least going through the established motions, regardless if you’re a believer or not.  If you don’t then it’s not going to be very effective.  Both need to fully understand their roles and what’s expected.  In my experience, if the Product Owner or ScrumMaster don’t understand and execute their role the Team will not buy in and Scrum will fail. 

Daily Stand-Ups: I’m a fan of daily, focused standups around a Scrum Board, a core technique used within Scrum, regardless of the project phase - even in the Execution Phase. It’s a simple, quick way for team members to get an update on what everyone is doing and how the team’s work may affect them.   In this case I’m an advocate of doing it “by the book”.  Stick to the standard “What did you do yesterday? What are you doing today? Do you have blockers?” line of questioning led by the ScrumMaster, keep it short (no longer than 15 minutes), keep it small (7-11 people) and do it live.  If a large team is broken up into lots of stand-ups make sure the ScrumMasters are having a “Scrum of Scrums” to share data between groups.  Some teams prefer to rely on software only like Hansoft, Rally or Greenhopper in place of the meeting around the board.  I personally prefer keeping it tactile instead and using the software in conjunction.  Information shared by teams actually meeting face to face is valuable and sometimes the information shared next to the water cooler after the standup is even more so. 

For the producer, whether or not he or she is the ScrumMaster, Product Owner or on the Team the blockers raised in the stand-up should take the highest priority.  They are the highest immediate risk items and will reduce the productivity the most.  Watch for them and kill them.

Scrum Board: I like the Scrum Board a lot.  I like that it’s a meeting place for the pod or team around the work daily.  I like that it’s easy to see work being done.  It can take up a lot of space and without proper maintenance it tends to get messy.  Just remember to keep it simple and limit it to the following categories: Sprint backlog, Doing and Done.  Other agile methodologies have more complex boards but for what we do it’s not effective.  Remember, simplicity is key.  I’m not a fan of keeping the board in software alone.  The tactile, highly visible wall has a lot of benefits and promotes team communication around work.

Burn Down Charts:  Both Agile and traditional project management advocate collection of metrics consistently.  I agree with this and believe that metrics help establish predictability.  The burn down chart is one way to collect data and help plan upcoming sprints. It’s not perfect but it’s something you can analyze and track.  Team members may balk at this since it seems like production is attempting to be the Eye of Sauron.  While that’s not exactly the intent since it’s really about daily checking on the team velocity toward the end of the sprint it could certainly be used for this.  After all, a responsibility of the producer is also about keeping team members accountable.  Trust, but verify as they say.

Planning and Review Meetings:  Both of these meetings are another aspect of Scrum that I find valuable but like most tools they have a place.  Planning Meetings are team or pod meetings where the backlog work is chosen for the next sprint.  Review Meetings are designed to review the work complete from the previous sprint.  If not run correctly they can devolve into chaos and they will lose their value.  The producer needs to understand how they should be run and when they should occur in phased development.  Planning Meetings are most useful when much of the product work is unknown.  In both cases I’ve found, even in the concept phase, they are not very useful to do as a whole team if there are a lot of team members working siloed (i.e. their work is their own and it’s agreed that no other feedback is required presently except from the Product Owner.  Usually this can occur with initial design spec write-ups).  Planning meetings can be chaotic and ineffective.  Sometimes a sit down with the Product Owner is much more useful when team members are working on siloed tasks. They most are valuable when a small pod of a few developers from a variety of disciplines are working on the same prototype or feature.   Also, I’ve found that Review Meetings performed to review anything other than a tangible asset (piece of art, working prototype, etc.) for the software aren’t very effective.  If the project is very early and working on simple documentation they can turn into a “verification of work done” meeting and that’s not the point.  It’s not meant to be a “prove to me you’ve been busy” inquisition meeting. 

Retrospectives:   These are basically simple meetings conducted at the end of sprints, usually after the Review Meetings.  They are essentially mini-post mortems and encourage self-refection and process improvement.  They are also called “look back” meetings.  I like these a lot.  They can be as simple as asking each person “What went right? What do we need to change for the next sprint?”  Assuming your team is no more than twentyish it can go reasonably quickly if done regularly.  If it’s larger the meetings should be split up based on the logic of the work breakdown.  It’s important for the team to participate and be honest, but to do so they need to know that they are protected from their comments and in a safe environment.  This can only be built with trust between the team, Product Owner, ScrumMaster, Producer, Project Manager and Stakeholders.

Sprints:  These can be fairly useful in all phases.  Typically they are time boxed from two to four weeks.  Think of them as focused work sessions for a short duration.  The best ones tend to be themed around a key deliverable that focus the team on a singular goal.  Working, integrated software prototypes across disciplines benefit a lot from sprints.  Alternatively, I’ve found they are less valuable when team members are siloed working on less related tasks.   The best sprint results come from collaboration and time boxing helps guide the team toward a collective goal.  Ever notice how much work gets done right before a milestone is due?  Sprints are like milestones every two weeks except they are focused on showing work to the team not some execs that may fly by every three months.  They are also useful as measuring tools to see how the team is progressing toward the ultimate goal of product delivery.


For the purposes of this article I assume projects have seven distinct, overlapping phases: Initiation, Concept, Protoyping, Pre-Production, Onboarding, Execution and Conclusion.  In a future article I will go into depth about what I believe is included in each phase.  (Some of you may notice I don’t adhere to the exact PMBOK definitions but thematically I’m generally aligned.)  Overall, my biggest gripe with Scrum when it’s adhered to strictly is that it’s most effective when the work is unknown and changing, not in Execution phase when it should be fairly understood.  By definition when a project is in Execution (i.e. full production) it should not be fundamentally changing.  It will be modified, tweaked and refined but the core mechanics, gameplay, art direction, technology or systems should never change at their most basic, foundational level during this phase.  If this occurs then the previous phases did not achieve their goal.  Agile methodology, of which Scrum is a member of, encourages and endorses fundamental change right up till release, which I find to be misguided for the reasons noted earlier.

This is not to say that things like daily standups, collaboration, etc. can’t still be useful in modified forms.  Often, during execution standups are for functional leads, producers, etc. as reports of assets, design mechanics and code are transparently discussed.  They may turn into regular daily hour long meetings which can be effective during this phase.

I will caveat this, however.  My assertion does not take into account market alterations late in the project cycle.  For instance, if you’re working on a title that is strategically initiated by the organization as a market definer of “X” but six months before release another product comes along that blows your X out of the water and negates the original strategic initiative the organization will have to rethink the strategy.  It might be that the original goal need to be changed so that this risk is accepted (kind of an “oh well”, that’s the way it goes” moment) or the original strategic goal of being a market definer is retained which will likely cause the team to delay the title. 


One last issue I have with Scrum is its tendency to be "ok" with moving tasks to subsequent sprints if they are not completed in the current one.  While this is going to happen I'm not comfortable with a methodology that gives implicite approval that this is a good thing.  Teams need to be held accountable for doing what they say they are going to do.  Generally, if a person or team is continually missing their estimates is likely that the planning for the sprint wasn't detailed enough.

    Author note:  Check the comments section below for a great discourse on the above point.


At the end of the day Scrum can work and work well.  It has its flaws and is rigid. I think it’s this rigidness that turns a lot of people off.  Were it more flexible like some other Agile methods then it may not get the undeserved bad wrap that I’ve heard discussed in hallways and carpools.  With a little training and education producers can be the ones to help the team get past their misgivings and onto acceptance and real work. 

As always, these are my own experiences and I realize there are much smarter people in the room.  If you have differing opinions please feel free to post.  You can also reach out to me at



Related Jobs

Demiurge Studios, Inc.
Demiurge Studios, Inc. — Cambridge, Massachusetts, United States

Senior Software Engineer
CCP — Newcastle, England, United Kingdom

Senior Backend Programmer
Guerrilla Games
Guerrilla Games — Amsterdam, Netherlands

Animation System Programmer
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan



Clinton Keith
profile image

Great article! You hit on many of the issues and points that I hoped you would.

I agree that much training makes Scrum come across as "too rigid" and that's the wrong message. Scrum is a starting script for agility and as a team and studio adapts to being more agile, then changes are necessary and practices from XP, Kanban and the PMBOK, to name a few, should be inspected.

I often point to the first agile value: "Individuals and interactions over processes and tools" to also cover "agile processes" as well. Following any process without question leads to failure. I've worked with over 150 studios as a trainer and I've found the most successful teams own their process and don't just follow a set of rules.

Also, I agree with your concern about principle #2. Video games are unique in that their development cannot be as agile as prescribed, especially deep in content production. This implies more project management than agile teams outside the game industry might need.

Thanks for the remark about my training. These days, I exclusively train video game teams in Scrum as well as Kanban and project management practices I found useful as a video game developer. Since you mentioned some of the useful books, I'd like to humbly plug mine called "Agile Game Development with Scrum":

where I also cover other practices.

Clinton Keith

Harvard Bonin
profile image
Thanks Clinton! I am very appreciative of your comment. I am actually going to add a point shortly regarding Scrum's tendency to be "ok" with tasks overlapping to subsequent sprints. I'm looking forward to hearing what you think.

Clinton Keith
profile image

You're hitting another key point. There has been much debate in the Scrum circles about sprint commitment vs. forecasts. "Commitment" aligns with your "scrum vs. accountability" comment, while the argument for using the term "forecasts" say there is often too much uncertainty to commit to precise estimates and that sometimes a goal has to slip a bit for the sake of quality.

My personal guideline is that I like to see a team hit their goal (collection of backlog items they estimated they could complete) about 75% of the time. Teams that hit their goal 100% of the time are often not challenging themselves as much as they could and/or they are excessively padding their estimates, especially with new/uncertain features.

Why allow any slippage? To use an example: on my last team it took me 2 days to implement a physics feature, as predicted, and then an additional 8 days to tune it to be playable, which I hadn't predicted as accurately. After a conversation with the product owner, I spent the additional time and as a result we dropped a lower priority feature. This wasn't a bad decision for the PO to make. I don't want teams to drop emergent work, like iterative tuning, automatically because they didn't anticipate it in sprint planning. I'd rather have them discuss the quality/cost tradeoffs with the product owner and, if necessary, adjust the goal if the PO wants the higher quality.

On the other hand, teams that miss their goal too much are not being accountable enough. Ironically, that's easier to coach them to fix. Sometimes, as you point out, they just need to plan better.

I still prefer the term commitment, but in my opinion, the commitment is, first and foremost, to quality (fun & done) and the forecast is the actual plan to achieve it. In my observation, teams with a sense of accountability and ownership of the plan just deliver better results. Coaching them on how to get there is a big part of the producer role.


Harvard Bonin
profile image
Hi Clint,

I definitely see your points. My general concerns are ones that I've experienced in person. When a team is working in short sprints and missing (using your number) 25% of their work items I've seen them either

1) take the sprint goals less seriously since they aren't achievable.
2) suffer morale issues since they are not achieving a high enough degree of success.

In both cases I would lay the responsibility on the PO and ScrumMaster. For #1 above I'd say that the PO/ScrumMaster may not be holding the team accountable, not emphasizing the importance of the goals or for not making sure the planning meetings are truly detailed. For #2 the PO/ScrumMaster may have not communicated the need for iteration and the expectation for frequent change. Would you agree with this assessment?

Also, what are your thoughts on my assertion that Scrum isn't best suited for the Execution Phase?

In any event, its a privilege to have this discourse. Thanks very much for participating.


Clinton Keith
profile image
Hi Harvard,

I was unclear in my point. The 25% refers to the percentage of sprints where not all the work items planned for in the start of the sprint are finished. I expect 100% of all work items done in 75% of the sprints, and one or two dropped items in the other 25%. Certainly, missing 25% of their work items *every* sprint is unacceptable!!

But in that case, I would agree with your two assessments of the cause and would go after root causes from there. For #1, yes, the PO may not be holding the team accountable (the SM's role is not that, however). Another common cause is that the team isn't given the opportunity to be accountable, because they can't own their work. Sometimes, you'll see an SM who is behaving like a micro-managing lead and drains any sense of ownership from the team, resulting in less accountability.

Agreed #2 is best coached by the SM and PO. Sometimes, you'll find that teams aren't properly retrospecting on what went right & wrong to address this. I agree with your emphasis on the retrospectives in the article. Too many teams overlook what might be the most important practice!

By "execution phase" do you mean production (as opposed to preproduction)? If so, yes, many teams find that some of the Scrum practices don't mesh well (like time boxed iterations and sprint planning) during production. In 2006, we mixed some Kanban practices with Scrum (we didn't get rid of the roles and daily scrums) and found it worked better than either a scrum or waterfall approach for production:

Since then, I've given GDC presentations on it, written a chapter on it for my book and continue to write about Lean and Kanban practices:

The most common "tells" of a successful agile adoption is the continual questioning, measuring and adjustment to what teams do to make games. Once someone puts on the blinders because a book said something or they tell themselves and others "it's the way we do things around here", they've lost.

Which is what I really enjoyed about your article. I'm often frustrated with what people have been taught about Scrum in the past; that somehow if you stand in a circle for 15 minutes a day and answer three questions, some methodology fairy will fly in and sprinkle productivity dust over you. Your article reinforces that it doesn't work that way, but it can still work with the right approach.

Anyways, I appreciate the opportunity to discuss practical adoption strategies, rather than religious arguments, and your pragmatism.


Anton Kruglyakov
profile image
Hi Harvard,

Nice article! Execution phase is a hot button for so many project. Btw what do you think is a key problem, why Scrum is not good for execution/production phase? Isn't its due to execution is more about content production that is mostly sequential or there is other issues too?

And little bit of critique. I don’t think it’s correct to say, that Agile encourage ‘fundamental change’. Will it be PMBOK or Agile framework, in both cases you can have external and internal change requests. In both cases you’ll need to handle them, it’s just that most of the Agile frameworks do it in a less bureaucratic way.

PS: Also on ‘SCRUM VS. ACCOUNTABILITY’. Decreasing of velocity is not a good thing, it’s a point to discuss on retro. What you need is let them solve it and respect the team wisdom.

Harvard Bonin
profile image
@ Clinton. Yes, Execution = Full Production. I expect this is when the work is well known and the full might of the team is deployed in the march toward the finish. Usually, for huge projects it might be a year or so.

I'm interested in how much Kanban requires to maintain. I understand the motivation but, since I've not used it in practice, it seems a bit heavy weight in the maintenance department to me.

We are in 100% agreement regarding the blind adoption of any practice. I do like Scrum but I disagree with its diehard users that it can't be adapted in pieces assuming the practitioners know what they are doing.

Harvard Bonin
profile image
@ Anton. Thanks for the kind words. Your assessment is correct. Since Scrum is truly designed for changing, unknown work its not entirely suited for known, sequential Execution Phase. I've got another article coming defining (what I think are) the phases of game development creation.

It is true that both allow change but traditional project management (PMBOK style) is designed for work that's much more known than forever evolving software. In fact, Agile specifically encourages change late in a project. Traditional project management is clear in the impact and expense of these changes at the end of projects...thus discouraging it.

As far as your PS. point. Yes, we are in agreement.

Clinton Keith
profile image

Kanban is the least prescriptive of any framework (including waterfall). You start by just measuring what you do now and apply lean principles & practices as you go.

Dave Hoskins
profile image
Such a shame to work with people that need that kind of control. Such is game development and all the 'needed' individuals that find a niche to stick to. All these controllers are not really needed in game development and just add to the the lack of creativity in a corporate environment. Still, you've got a job after all.
Sorry. ;) - winking face to indicate I'm just taking the piss.

Marco Castorina
profile image
@Dave: I think you're missing the point. The very idea of agile is to allow short iterations and create prototypes to play around with ideas and concepts that might or might not work in the final product. But you can't prototype forever. As Harvard says, there is a time for experimentation in which big changes are allowed, but once you lock in certain aspects of your game, changing them late in the life of the project will be risky, painful and might not even lead to a better result.

I think the problem you mention is the fact that in bigger companies those prototypes are never even taken into account and only proven concepts get the green light; but that's a whole different discussion :).

Just my two cents.

Harvard Bonin
profile image
I think Dave was joking based on his final wink. Still, thanks for the support.

Joonas Laakso
profile image
Thank you for this article. I believe I'm far from alone in saying that it reflects my real-life experiences in game studios. It is such a shame that to get to this understanding, you generally need to stumble through implementing Scrum a few times and fall over on all of the problems.

I don't really agree with Scrum being the wrong way to do full production, but you do need more of a focus on making sure you stay on course. (For silo-ed art production it is the wrong choice as production art resembles a factory in terms of process.) You could make production levels or whatever using Scrum, but that would require the teams to be self-contained and fully cross-discipline.

Julian Cram
profile image
Hi Harvard,

Having dealt with a company which used "scrum-but" and a process which resulted in a crunch so bad they were investigated by a fair work organisation, even the slightest deviation from Agile recommendations makes me nervous.

There are people out there who do demand wholesale changes during the late stages of production, and won't take no for an answer.

I won't mention names, but these lofty fools swoop in with little knowledge of the project and request changes because they think a certain person above them doesn't like a certain style, and because they're answering to "the boss", this change has to be made.

If the company utilised scrum properly, these changes could have been incorporated into later sprints and their stupid egos and powertrips could be accommodated. Clinton even mentions how to deal with it in his book, and it took all my willpower not to copy the page and fill the inbox of all the remaining producers at that company with it.

Luckily I'm now working for a start-up which is completely Agile, and as a producer I have complete control of the production process. I allow for slippage, much like Clinton suggests. I make sure those lofty-type stakeholders are involved in the process to prioritise workflow, and if they refuse to or are "too important" to be part of this process, then I refuse them to be allowed to ask for changes. And for changes I allow from stakeholders, I inform them up front that any change comes with a cost - for example if they expand a feature and it goes from 2 to 4 story points, then we lose 2 story points from elsewhere.

Moreover, I have very competent Product Owners and Scrum Master who support me, and a team I can rely on to be accurate and work hard, and notify me of any issues without fear.

It's the difference between day and night, and I actually enjoy my job again. If I decide to stay late, it's because it's a decision I've made.

And if I ever got offered a job in a studio which did scrum-but, I'd be very reluctant to agree to work with them without some other kind of assurance as to work-life balance.

Mrugesh Panchal
profile image
“the very nature of Agile development would by definition negate the need for late changes due to its iterative process.” Not necessarily true. The main principle of Agile is to “inspect” and “adapt,” and to incorporate “changes” as and when they occur. The scrum project should be able to changes even when they occur late during the development.