My team is using Sprint goals in the wrong manner. How can I ask them to change?

[-]

segfaultsarecool@reddit

I've never understood the point of a sprint goal. Isn't the goal of a sprint to complete as many of the allocated tickets as possible while maintaining high quality?

[-]

If you're working on a product/program/project for which there are large meaningful goals, then it makes sense to use scrum methodology and set actual goals for each increment. I.e., get the onboarding form working, implement auth, etc.

What you're describing is really more aligned with kanban - there is a steady flow of varying business requirements that are generally dictated by the business and you have limited agency to choose what you're working on.

I prefer kanban in these types of scenarios, it's usually easier to increase velocity because it decreases procrastination, and I find scrum becomes too bureaucratic when you're not setting your own goals. The biggest challenge is usually convincing senior management to tolerate it because many of them are conditioned to believe scrum is some sort of holy instrument incapable of producing inferior outcomes.

[-]

BanaTibor@reddit

If you have sprints you are must using some framework, scrum or similar. All should advocate for a regular retrospective meeting. Bring up the problem there.
It is important to have a solution in your mind as well, or at least a proposal.

[-]

Xgamer4@reddit

I've never worked at a company that even pretends to set sprint goals.

The idea is appealing - define a business-oriented purpose to be the end-state for the sprint. But in practice it seems to require that both the business/product side actually have a defined goal in mind, the product managers be aware of that goal, the team leadership being aware of and buying into that goal, and the actual engineers having enough business sense to care. Which seems to require a certain degree of forward planning and sophistication that I have yet to see.

And that's assuming it's possible. Any team in maintenance mode just flat out isn't going to be able to define a sane goal beyond "make less bugs"

[-]

Drugbird@reddit

In my experience, it's usually that a Sprint isn't long enough to achieve meaningful business goals. I.e. sprints last 2-3 weeks. A new, fully implemented feature that a user can use takes 1-6 months to create. So there's many sprints where there's little business value being created.

I find the Sprint goal is only every "complete the user stories and features that are scheduled for the Sprint", but that's highly redundant.

[-]

NiteShdw@reddit

This is why I prefer Kanban. It's project focused rather than time focused.

[-]

General-Title-1041@reddit

thats because sprint goals were a thing when it didnt take a developer 1-6 months to make a feature that should take a week rofl

[-]

HopefulHabanero@reddit

^ This. My team has similar practices as OP's seeing. Our problem is not that we don't understand or respect scrum, it's that we've been given a top down mandate to use scrum with two week sprints despite it being a poor fit for the type of work we do. So we deal with this by half assing all the scrum ceremonies while doing our actual work in a more kanban style.

In an ideal world, we might try to push back against leadership and insist we be allowed to choose our own process. But thankfully nobody is paying much attention to our process so long as work gets completed, so there's not much reason to shake the boat.

[-]

PragmaticBoredom@reddit

I’ve never worked at a company that even pretends to set sprint goals

I’ve worked at a few companies that wanted us to do sprint goals. Occasionally it worked. Most of the time we were just exhausted after hours of unnecessarily formal sprint planning, so coming up with the sprint goal became an exercise in writing something that sounded passable so we could all get back to work.

Everyone promptly dismissed the sprint goal and started working on their tasks.

The sprint goal exercise is redundant if you’ve already assigned tasks according to your goals. Just let people work on the assigned tasks.

[-]

gabeqed@reddit

This is exactly how it is in any corporation or big enterprise. I’ve never seen this actually be done in how it’s described in these articles and books on scrum. It’s just not possible with the amount of politics and pushing and pulling at different leadership levels within an org. Just play along and don’t rock the boat.

[-]

Feroc@reddit

I really like the sprint goals, in one team they really helped me to stop the team working side by side, each on their own little task and at least try to focus on a common goal. But in this case it was an issue we identified as a team and the team was open to try something like that.

Now the big question comes with this part:

We work on seperate areas of the product and I dont think a unified sprint goal is possible, and I dont get what we're doing here. Feels redundant at best and malicious at worst.

Is the problem that your sprint goal is redundant, because you basically summarize the sprint backlog after you created it or is the problem that you are working as individuals instead of a team?

I said this more than once: Scrum isn't good at solving problems, but it's very good in uncovering them. In this case it uncovered that you are not actually working as a team. Now there are surely good reasons why you don't do it, some may be valid, some may be "because we always did it that way". That's what your Scrum Master should figure out.

[-]

xelah1@reddit

Don't do stuff just because the Scrum guide says so. Work out what it's for, whether anyone actually wants that outcome and whether what you're doing is useful to achieve that.

You have to decide what to work on next. How are you going to do that? How are you going to choose stories for your sprint? Well, you could summarize the next few things that someone with a product-oriented vision or who talks to actual users thinks are the most important new capabilities. Now you have something you can compare candidate stories for you sprint against to see if they should be in or out. It may help you identify missing stories, too. It's a link between broader strategy and short term choices.

If you already know what you need to do next at the story level then why bother with that? You don't need it. Alternatively, if there's no-one who has any vision or idea of what new capabilities matter most then there's also no point bothering with it - it won't conjure vision out of nowhere.

Doing this backwards as you're describing is pointless (unless, perhaps, it's being turned into a summary for someone's slides).

If you're in a position of sufficient power you could find a time to suggest not doing this. If not then just list your tasks and forget about it - it's going into a black hole anyway so it doesn't matter that it's 'wrong'.

[-]

Kajayacht@reddit

When I try to explain the idea of sprint goals to teams, I describe it as “The sprint will (should) end with a demo to the stakeholders. What is the one big headline thing we want to show them? That is the sprint goal. We then pick items from the backlog that will move us towards the sprint goal.”

I feel like it’s a really good way to think of sprint goals, but I’ve had limited success in getting teams to start setting good sprint goals, so who knows :D

[-]

lab-gone-wrong@reddit

Don't invest your precious time into arguing about the definition of work-about-work artifacts. This is not a hill worth dying on.

If you really want to push back, argue that sprint goals are unhelpful in practice and should just be dropped entirely. It is generally not possible to deliver a meaningful business outcome in 1 sprint except at early stage startups.

[-]

Mac748593@reddit

Sprint goal: do the things we said we were going to do Standup: did the thing I said I was doing. Moving onto the next thing I said I would do. No blockers except this meeting.

[-]

WheresTheSauce@reddit

I’m sorry, “malicious”?

[-]

MrMichaelJames@reddit

I hate defining goals. The goal is to finish the stuff in the sprint. Simple as that.

[-]

bulbishNYC@reddit

Scrum ceremonies become useless too, since no one listens because everyone is working on a different thing.

And you can’t stop doing scrum because all management bought into the cargo cult

[-]

TopOfTheMorning2Ya@reddit

And most of the time it would be weird if everyone was working on the same thing. It would take extreme coordination for like 6 people (or even 2 for that matter) to code and test a story together. It’s just easier and faster to do each story individually. For training and knowledge sharing it could be better for people to work together but that’s about the only benefits.

[-]

bulbishNYC@reddit

Same thing I mean not same ticket, but completely different epic/project. It’s ok for 6 people to work on 6 tickets from same project. But when they are working on 6 unrelated projects it’s a pain.

[-]

TopOfTheMorning2Ya@reddit

Depends how closely related the tickets are. If they are 3 coding changes in the same project it can get messy. Especially if they touch any of the same classes.

[-]

zaibuf@reddit

Sprint goal: Doesn't matter, whatever C-suite decided.

[-]

CompetitiveSubset@reddit

Tell them to Scrum deez nuts.

Seriously.

The initial intent was probably worthwhile - a way for management to get a sense of what is going on but yeah, it turned out weird. I wouldn’t call it malicious tho, just strange. Your best bet is to try to not get too much upset about it and go with the flow.

[-]

DualActiveBridgeLLC@reddit

Sprint goals are supposed to be the North Star of the sprint, and success is demonstrated in Sprint Review. They also help you evaluate reoccurring problems during the sprint retro. After 1 year in the project I looked for patterns in which sprints we failed. And there was a glaring observation, when we were dependent on another team we had a 50% chance of failing the sprint. Showed it to my boss and we made a plan to fix it (this is what soft skills looks like).

Goals are not tasks because tasks do not mean anything to the stakeholders.

[-]

Alpheus2@reddit

It’s frustrating, I feel you. I coach leaders and POs to get off of the scrum bandwagon.

A goal is great though, it gives a shared “why” for everything that’s in the current sprint.

It can also be redundant if the sprint goal is “everything that’s in the sprint log”. This seems to be your case. It’s okay, your leads will learn but they need your help.

Wouldn’t it be great if you could all just build great software without getting caught up in bureaocratic ceremony?

Here’s a few pointers: - Ask “What common delivery joins the different teams/paths together? Who owns that part?” If you get an answer, encourage the PO to make THAT the sprint goal - Ask “When do we cancel the sprint?” - Create awareness for “Is anything more important than “sprint goal”? - If you discover another parallel needs help, how much time before the end of the sprint does it usually take to course correct?

[-]

centauriZ1@reddit

Change the process for the team, not the team for the process.

The question should not be "does this conform to the Scrum specification", it must be "does this work for our team".

Of course your characterization of "redundant" and "I don't get what we're doing here" may indicate the process does not fit your team.

[-]

MachineOfScreams@reddit

The worst dev teams I have been on tend to be the ones that try to stick the closest to agile/scrum playbooks (SAFe being the worse). The real question to ask is: are you delivering what the customer/client/organization needs? Is productive work being done?

Sprint goals, burn down charts, etc are all just measurements rather than being the goal itself. But plenty seem to think of them as the end goal (achieve maximum burn down rates every sprint).

[-]

Far_Archer_4234@reddit

"Hey motherf*ckers! We should change the way we are using sprint goals." Might be a good place to start?

[-]

all_city_@reddit

Lol do you work where I work? We do the exact same thing

[-]

OverEggplant3405@reddit

I think you're on to something that this is off, but after reading some of your replies, I think you're caught up in framing it around whether or not you are following the blessed process. Instead, you should be focused on understanding the impact to your company and team.

What you described could mean that there's a lack of coordinated focus on goals and that success is defined by obedience and execution, not outcomes.

You yourself show this attitude in the way you describe the problem.

If there is a lack of focus on results from management, it's unlikely you will change the culture of the company. So, I would look elsewhere. But, if you want to replace these processes, come up with better ones.

[-]

bulbishNYC@reddit

This did work well for us in startups. We were doing a lot of rapid greenfield development, copy this feature from Facebook, copy this other one from Uber. Scrum was perfect for that.

In big corporate it’s not working at all. Heavy maintenance workload, big codebase, many slow moving projects, out of greenfield ideas, difficult projects where there is Facebook to copy from. Everything is slow moving and fragmented.

[-]

keelanstuart@reddit

Agile development isn't real. The concept has largely been co-opted by management types so that they can feel like they did "something" to improve the output of software engineers. But they barely know what that something is and don't get the point... which is simply to time box subjective outputs (so that you don't spend a year working on a GUI that everyone hates when they would have known they hated it after 3 weeks) and to measure output over time so that estimates are better.

My company is so fucked in it's use of agile that people "take credit" for "partial story points". Our customer requested that we move to an agile process... and they eat it up. I fought against it at first but finally just laughed and did my work.

So my advice to you is this: ignore the game / play along (or at least see it for the game that it is), do your best, and make sure people know your value. Stop asking people to change.

[-]

Breklin76@reddit

The only thing I still do after being on a few teams attempting to do agile is have the daily “stand up”. 30 min in the morning. Lead by our director. We go over each other’s tasks, open it up for demos or help requests or just to shoot the shit for a few min. We are all remote.

[-]

budd222@reddit

Then talk to your PM about if you care that much. I bet nobody else cares so I imagine you won't get very far. I don't think it matters much anyway.

[-]

Breklin76@reddit

It’s simple. You point out that you have noticed your teams approach to agile isn’t in alignment with common practice and suggest ways that each if you can contribute to refining your process.

Just talk, dude. 🙂

[-]

13ae@reddit

i'm confused, what's the problem here? processes like scrum are just a means to an end, what inefficiencies are caused by this and what's your proposition to make it better? simply saying it's redundant at best and malicious at worst just sounds like a platitude to describe your annoyance at having to type out an extra sentence every 2 weeks or however long your sprint is.

[-]

araneid@reddit (OP)

I dont have an issue with typing out an extra sentence.

The thing is, what we call sprint goals is essentially just a bad quality snapshot of the sprint board. Why do this? And when I suggested that the team isnt suited to sprint goals, I was ignored. They said it was for accountability. How does parroting your exact sprint tasks as sprint goals add accountability?

[-]

13ae@reddit

The problem with this, is that in the time it took you to write this reddit post and have that discussion with your team, you could have written down a year's worth of sprint goals in the slack channel.

If you don't have stronger justification outside of "this seems redundant for our team and i disagree that it adds accountability", you're just wasting time nitpicking something that doesn't matter, and showing everyone that you don't know how to prioritize what's actually important.

[-]

fired85@reddit

Hired.

[-]

Echleon@reddit

Have you asked your team that question?

[-]

_ncko@reddit

What is the end? If it is to just build stuff, then I agree. This workflow is fine.

If the end is to increase conversion rates, or optimize a sales funnel, or improve engagement with a particular feature, or decrease the amount of time it takes for internal staff to complete a particular task, or some other outcome, then I don't think this workflow is good at all. There is no mention of measuring or tracking something that matters and it doesn't seem like they can iterate and improve their metrics.

[-]

Shazvox@reddit

If it works for your team, then it works. If it hinders your team then bring it up. If it doesn't hinder your team but doesn't seem to bring any benefits then ask your team for clarification of the purpose.

What you don't want to do is go "we're using it wrong, scrum sais X and we're doing Y".

[-]

badlcuk@reddit

I’ve been in a similar situation. I’m assuming you’ve already tried the “question value and try to nudge them to the right usage” angle and it’s not working? If so - how about just try to just get rid of it. Point out it’s a waste of time since it’s redundant. I found was easier to convince them the style they’re using it in is not useful than to try to convince them they were wrong. Remember, people over processes. If the process isn’t helping, dump it

[-]

rwilcox@reddit

I like the idea of sprint goals being things you can’t track on the board. Like “turn PRs around better” or “one less outage”, along with the business like, “be able to turn on the foo system to 10% or traffic”. It’s the way I’ve seen to take this thing that’s normally checkbox filling and turn it into something.

You could certainly bring it up in the retro about changing spring goals. Now, about 50% of the time if you’re in a company that has retros, engineers actually trying to change the process is verboten, but you could try (it’s actually what retro is for)

[-]

Comprehensive-Pea812@reddit

perfectly acceptable

[-]

GoTheFuckToBed@reddit

A clear goal that is understood by all team members is very powerful, and improves producdivity by about 20%.

We are not doing it at the moment and we are paying

[-]

deeetz@reddit

I agree that this is not the purpose of sprint goals. OTOH I rarely saw good spring goals, and even in the better teams/projects they were a bit hit and miss.

I also don’t see how they can be exploited as you suggest.

I wouldn’t sweat it to be honest. Bring it up in retro. If you don’t get buy in, leave it.

[-]

SoulSkrix@reddit

I’ve only ever seen this respected in smaller sized companies (< 250).

[-]

editor_of_the_beast@reddit

You didn’t explain what your team is doing. Or are you saying asking you to post updates is what’s wrong? What’s the issue here?

[-]

nutrecht@reddit

This really sounds like a fight that's not worth fighting. It's redundant, sure. But malicious? That's a massive overreaction.

[-]

robben1234@reddit

Teams and individual contributors are judged by their deliverables.

Sprints and the whole agile is a game to make those deliverables happen in manageable increments with opportunities to correct mistakes.

If the team finds the additional whistles useful no one would object to them doing it. But it seems you want the team to spend effort on whistles no one but you is finding useful to making progress on actually important things.

[-]

gemengelage@reddit

Yeah, in my experience "sprint goal" is a stupid redundant text field in Jira and if I'd put nothing in there or just "do your job" every single sprint, nothing would change.

[-]

Grubsnik@reddit

What we did at my last place was agree on 3 items/events/collection of things that we wanted to see happen. So there might be way more tickets in the sprint, but at a high level, we defined a must reach, a may reach and a nice to reach goal. That helped people to focus their efforts during the sprint, because by day 3 you would otherwise only see the current things and any new things that had cropped up

[-]

ProgrammerPlus@reddit

k? Just tell them how you feel?

[-]

Kukaac@reddit

If you work separate areas of the product your spring goals are the smallest concern. Your are not a team, but a group of individuals, so you don't need planning together.

[-]

SpiderHack@reddit

You shouldn't ask them to stop, you should instead ask them to focus more on how their task is going and to list any [stumbling blocks] they are facing. (less 'severe' then a 'blocker'), but also allos earlier help to be given, especially to junior devs or new devs on the code).

This alone would(can) be a minor tweak to the process that would(can) see massive acceleration of people getting over [stumbling blocks] (depending on the devs, the code, etc. obviously)

[-]

_ncko@reddit

I've never seen a team that understands sprints, scrum or "Agile." They're all output oriented. They're all waterfall, with an iterative loop at the end where developers "work on x, y, z and resolved bugs related to t, y, u."

If you're also output oriented then maybe you can propose a sprint demo at the end of the sprint. Then you could push at the beginning of each sprint for a discussion on what you hope to demo at the end. That becomes the sprint goal.

If you're outcome oriented instead, then I don't know. I've never been able to get any of the organizations I work for to be more outcome oriented.

[-]

davearneson@reddit

Ask your product owner to set a real business goal and then select your backlog around that