This is the second summary of agile podcasts, as described here.
It depends when. It’s not a requirement.
Defining the task often implies the “who”, so don’t create tasks when they’re refined and ready to be put in a sprint. Bob and Josh have differing opinions on this:
Bob says:
The sprint planning meeting is where you do the decomposition into tasks. You estimate the tasks in hours.
Josh used to do this, but not anymore. Two reasons:
…so Josh stripped out the tasking part.
Bob feels tasking is another level of grooming you do. You talk about the who and the how, and it’s the communication about these things between the team that matters and brings value (who is the right person for this task to maximize our throughput, our quality, etc.?).
It helps to identify dependencies in time (only for that sprint, and only for the team!), so the PO and team can see the progress of a story in time (first, the developer works on it, then it gets validated, etc.).
It also helps to identify bottlenecks: if a critical person for this sprint (say, for validation) is only available part time, but the rest of the team will be generating work for that person, the team is going to run out of that person’s time - a bottleneck. Not tasking means these things aren’t discussed.
Josh does story kickoffs instead - at the time the story is actually picked up, the team discusses the tasking (who, how). It’s more real time planning.
Both agree that Shu teams should do tasking. A Ha team would probably wonder whether trivial stories need tasking. They may also limit story points to one size, or a limited set of sizes. At that point, the flow goes more to Kanban and no estimates.
Story points may also be used as weapons by management, and at that point, a Ha team does good to simplify and get rid of them.
Bob and Josh note that some teams don’t take a break, because “it’s not in the book”. But from time to time, you need to celebrate!
Bob did it after each release train of 10 weeks, consisting of a 2 week break with a 2-3 day hackathon, re-energizing the team.
Good Scrum Masters keep a pulse on the energy of the team and recommend breaks when needed. Bob and Josh had a budget for at least quarterly team building events (or lunch, or …). What’s important is that the team decides the activity. Otherwise you get forced fun, which really doesn’t work as well.
Keep the team members in mind - younger team members might want to do a game night, while older team members might prefer a movie night with their significant other. In a diverse team, it’s going to be hard to find activities that everyone will like consistently. It’s fine to have split activities sometimes based on these interests.
Bob and Josh then provided a few practical pointers:
This is the stuff that will get you high-performance teams.
To conclude: have fun, create space for fun, and the little things count more than the big things.
Krisztina Sajgo-Kalo talked about being in a Scrum Master role, but she had problems with letting go of the more traditional way of project management.
She begins the story as such: there was a new team that did ops work. But they didn’t want to do standups, so Krisztina just took the lead in each standup.
At the start, these standups often consisted of 35 minutes of complaining: they wanted someone to take responsibility and have someone else solve all of their problems.
So she focused on retrospectives (which were “quite heated”) to discuss these frustrations. Again, people were complaining at the start, saying things like “why are we responsible for this, this is not in my job description!”.
But by doing the retros and sticking to them, the team matured, and addressed the ownership problem they had “in their minds”.
But Krisztina also had to learn:
Krisztina said something that really resonated with me:
Never take away responsibilities from the person, no matter how hard they try to give it to you.
Just as Krisztina had to let go of being a more traditional PM, the team had to learn to be self-organizing.
She gave a practical example of this shift: during retrospectives, she clarified to the team what they could and could not affect, and she used that list during standups. With this quite strict interpretation of what an “impediment” was, she could identify the things the team could solve and would ask the team to resolve them. If the team could not solve it, she would add it to her list of impediments and get to clearing them.