A tongue-in-cheek explanation of scrum with a pinch of salt.
Refinement: in a Refinement Meeting, the
business analysts introduce the desired features (= user stories), and
the developers estimate how complex these are to implement. If you are lucky, you deal with an experienced team and the estimation of each story is a matter of minutes. At the worst case the
estimation is based on limited background information or even total
disorientation on what is really behind these stories.
Weird thing is that some companies prefer the term "Grooming" over "Refinement" although I recommend not to use it. Grooming is another word for child abuse...just be aware of that.
If one realizes that a desired story is too complex to be done within a reasonable time-frame, it must be stripped down into smaller stories until each of them fits. Even during a sprint you may deal with the situation that certain tasks of the story cannot be implemented
in time and therefore require business analysts to further breakup the story into smaller pieces. The more stories requiring refinement the higher probability of losing overview of
the great picture. At one point in time you may not see the wood for the trees.
Sprint Planning: The team discusses the goal of the next sprint; which is the tasks and user-stories that need to be implemented. Some now detect that the estimation of some user-stories is too low and correct those on-the-fly, so one cannot add too many stories to the sprint. In order to understand what you can put into a sprint, you also need to know your capacity. If you are new to agile processes, you can't know the team's capacity. Usually you will learn after a few sprints what is the typical team's capacity.
I've been at a company where the planning was a matter of 20-30 minutes while at another we had endless discussions and calculating velocity etc., then everyone agreed although it was already clear there was little hope one really manages to complete these tasks.The only group of people who believed they meet the goal were the managers.
Sprint: Usually a 2-4 week work phase where one implements what was agreed in the sprint planning.This is also the phase where some people realize they wanted to go on holidays and just didn't say anything before. Others realize they go to a workshop, yet some others
become ill. At one company it was common to regularly check whether ot not the sprint goal could be met. If there were indications a task could become too big or other tasks could become more important, it was normal to take tasks out of the sprint and re-prioritize. In another company the sprint planning was seen as a strong agreement between the product owner and the team and it was much harder to take things out.
Daily: In a "Daily", the entire team meets for a 15-minute briefing. Each individual has a minute or two (depending on the team size) to explain what you have done yesterday and what you are planning to do today. For people who are not familiar with this kind of briefing (especially when they are new to agile processes), such meetings can be mis-understood as an awkward instrument of micromanagement. As a result, during the briefing they try to convice others how hard they worked and that they will work even harder today.
Others are so enthusiastic and would like to have the complete 15 minutes just for themselves. As a result, one hardly finishes in time. Some of the team-mates have no clue what others are talking about, others polish their nails or check the latest news on their mobile phones or make notes for the next meeting where they will do the same for yet another meeting. From a good friend I heard their team had to do planks while they were speaking. This helped guarantee they didn't talk too much. An external consultant once suggested to snap off the meeting after 15 minutes regardless whether all team-mates had a chance to talk. I think such advice is ridiculous and counterproductive in regards to building up a motivated team.
Burndown-Chart: The burndown chart is a two-dimensional graph designed to track the work progress during the sprint. In the beginning you have a lot of work in TODO and near the end ideally nothing should be left to do. At the best case, the graph shows a nice consistant stair going down from top left to bottom right. However, reality is sometimes different. The graph often shows a straight line without any indication of movement until shortly before the sprint ends. The graph then looks like the path of an airplane that all of a sudden disappears from the radar. The poor guy is the tester who gets thrown half-done tasks over the wall to test in zero left time-frame.
Sprint Review: That's like payday. Developers demonstrate the outcome of the sprint. This is usually the day when we see a lot of astonished faces.
Retro (retrospective): After a sprint, all team members have the opportunity to comment on what went well and what didn't. From this, measures will be taken for the next sprint. Don't be surprised if after the meeting, people have already forgotten what they just discussed and agreed on.
Story Points: Although story points have nothing to do with scrum (invented by Mountain Goat Software), many companies use these to estimate their tasks. Story Points are a bit special because they don't tell you anything about how long a task
takes, but rather how complex a task may be to complete. In theory, a
task can be very trivial and still take longer because it may invole a
lot of monotonous activity to complete the task. On the other hand, a
complex task can be completed within an hour or day depending on the
skill of the one who is implementing it.
Although I have worked with Story Points for the past 10 years, I am still swinging between two different mindsets. I still can't decide if it is a cool tool or just a buzzword. The paradox of this
measurement is the fact that on one hand you don't measure how long you
have for a task, but you still do it indirectly because you take these SP numbers to fill the sprint. This is per se exactly the same as if I measured the hours I have for a task, because we fill the sprint only with a limited number of hours/days available. But, story points help you understand much faster when a task gets too complex. Since you are using fibonacci numbers, you get alerted right away if you have a task estimated higher than 8. There is no 9, no 10, the next number is 13. This huge jump is a great warning sign and leads you to rethink the size of the story.
And the winner is...
Last but not least, as a test manager who has to keep an overview of what is going on in more than just one development team, visiting all the daylies of the teams was one of the best places to get a rough impression on what all teams are working on. I've learnt this way also what the DevOps team was doing could therefore be alerted if they were working on stuff that may have had an impact on QA.In the past...where I was working just for one team and it was much harder to get informed what other team-mates were doing.
