Can someone explain Scrum to me, like everything, what it is, why it's used, why it's effective, cases where it isn't effective, what the roles are etc, I've tried to understand it online but to no avail (need a childish explanation I guess)

To me, it's sitting in a room with your team, doing what has to be done, and asking someone next to you if you need something.

Or in other words: "Project Management by talking to each other"

I've never actually seen Scrum in practice. Just trans that day they practice it, but don't really.

Scrum takes what a good team does naturally, and then formalizes those things into a set of insufferable rituals that are expected to be done on a way too frequent schedule whether they need doing or not. Scrum then "timeboxes" all your activities into 2 week sprints so that you can be micromanaged from afar via Jira charts. Like many things in life, it sounds much better in a book than doing it in real life.

@Fell hmm that's pretty simple

@monkeyboy AHH ic

I wouldn't bother. I'm supposed to be Scrum master and I think that Scrum is overrated. I'm yet to see any benefit of it except for when your team had some pathetic organization and management that could be fixed in number of ways.

When I ask other SM about benefits and solid examples of those I get flooded with charts and coaching bullshit. It feels to me like some kind of religion.

Most of all it formalizes the communication part.
Talk daily about what you are working on and how it is going.
Keep track of the work via the kanban board.
And use overseeable deadlines (1 week to a month) with overseeable work (the stories that will be done during that timeframe).
Also of course there are the formalized retrospectives to learn about what went well and what went wrong and how to improve the next sprint.

This way everyone knows what needs to be done and when, everyone can see how it is going by looking at the kanban board. The daily stand-up keeps everyone talking to each other.

I disagree with people saying it's pointless. If you're a scrum master and you think it's pointless you're team are gods or you don't get it.

Scrum is a framework to help deliver aspects of agile.

You have a product backlog of user stories that a product owner gives guidance on for what the customer needs. These can change without impact on existing project so it serves more as a place to hold them. Stories are as small as possible whilst still maintaining functional value as that allows to slowly build software up in a way that allows for easy tweaks to features coming. Small stories also allows for small PRs that are easier to review, easier to understand stories and opens the door to clear testing with BDD tests.

Part 2 in second comment.

You decide a sprint length, usually about 2 weeks and you bring in the highest priority stories out of the backlog. (these should be pointed on complexity from the last sprint) you start the sprint by checking the stories are understandable as a team and then point more stories from the backlog for the next sprint. You do that twice a week maybe for 30 minute sessions.

After enough sprints you can see how many points where done (estimating time is too hard). Over time you build a velocity - how many points get done on average per sprint and you start using that velocity to decide how much work to bring in each sprint, with a little buffer for unexpected bugs etc. Now you can deliver work to your boss in time scales promised with confidence and you have a base line to experiment with improving that velocity.

You also ensure work in progress tasks are limited because an unfinished task moves to the next sprint and is not counted in velocity total for the completed one.

Now you naturally have a limit on work in progress and can control software quality easier by ensure work is not marked done unless it's also tested. There is less chaos and a better quality product.

Overall we now have a way to keep WIP open stories number smaller to simplify management and push things through, we have understandable work to do, we have small PRs to understand and keep quality higher, we can be more certain we don't over promise, we can improve since we have data we can measure over time, we can ensure testing is done well due to PRs that are clear but also testing team can do selenium tests easier since the acceptance criteria is simpler, the team knows what is going on in the project because there is better communication from the planning sessions and stand ups help with that too, we have a limit on blockers due to a cap on WIP, we have software that you can actually be more confident in which removes a lot of sick feeling in your gut for releases..

We also have delivered a product we know the customer wants since the product owner is or has a relationship with the customer and due to the incremental build of the software from the core of a feature outwards we also know the customer has what they want, Co sidering customers don't know what they want at the start even if they say they do we have eliminated pointless reworking of features and we can move on without having to look back constantly.

@craig939393 yes, that is how it supposed to work in theory. I myself have not actually seen that done. It's more of a passive-agressive thing. Everyone mods their heads, says, "Okay", and then goes back and does it their own way.

@craig939393 you have given a nice academic explanation. However, it leaves out the impacts. Work is divided into tasks that for in the timebox whether it makes sense or not. The backlog is controlled by one or more product owners and is completely out of control of Devs or anyone else with actual technical knowledge leading to nonsensical stories. As a developer, you have no autonomy. The process discourages expertise or specialization which reduces product knowledge and decreases product quality. The process incentivises management by metrics: DOD must include 80 percent test coverage (the stupidest metric on Earth), your velocity is down so you must be punished (which leads to under committing and large inefficiencies which leads to deception and an wisdom of trust). Ah yourself why getting things done required so many rituals, and how in the world did we do anything before?

@monkeyboy I don't mean it has to be used, just a what it aims to solve and why.

And the main points about a lack of autonomy or lack of developer control - developers should be part of the process all the way through and be involved in turning a product owners thoughts about what need doing into actionable user stories.

And a lack of specialisation just doesn't seem a factor to me since a single person can still own an epic, it just forces a break down for quality checks.

The real problem is where to cut an epic into stories that are not pointlessly small or too big and how to ensure the 1 pr to 1 small story work flow doesn't produce tons of blockers all the way through doing single epic.

It's not academic, I have worked on a team doing exactly this and some of my friends currently work like this if not better. For me though it's just a dream since my company does it shit xD