Ask any Agile practitioner these days what Agile values are and he,
most likely, will recite you some lines from the Manifesto for Agile
Software Development. As him the final line of the said Manifesto and
the result might be quite different, but I digress right in the first
Ask a Scrum practitioner and he’ll give you 3-4, maybe 5, if he’s real good, values Scrum holds dear.
Next ask a different question, “What ARE the values? What are we talking about here?” And you’ll be lucky if you hear a half-baked off-the-cuff answer. Sometimes it’s just like, “well, values are values, those are what’s valuable.” Duh…
Having distributed team members is always a challenge in many aspects in a scrum team. One of the challenges is performing a meaningful, effective and with good results retrospective. Shirly Ronen-Harel created this collection which will provide some insights on the subject: http://tracks.roojoom.com/r/73149
There is enough LS which you can use to make your meeting productive. However, if you have the feeling that they are overused or you are bored with them, think about the five elements and create your structure.
How Space Is Arranged and Materials Needed
How Participation Is Distributed
How Groups Are Configured
The sequence of Steps and Time Allocation
An example of a retrospective with a new team: Situation: we have a team of 10 colleagues. A developer and I had just started on the team.
STEP 1: Ask the group to create two teams and give them the following assignment per team:
Team 1: take 10 minutes to think of all the reasons why this team is the worst team ever. after the 10 minutes, try to convince me that I have made a bad choice to join the team.
Team 2: take 10 minutes to think of all the reasons why this team is the most impressive team ever. After 10 minutes, try to convince me that I have made an excellent choice to join this team.
STEP 2: After both presentations, give the next assignment:
Team 1: take 15 minutes to discuss within your team what actions can be made to keep the most positive things that team 2 had mentioned.
Team 2: Take 15 minutes to think of actions we can take to dismiss some of the reasons that team 1 had mentioned.
STEP 3: After both presentations, ask each one in the group to think about the actions mentioned in Step 3 and take five minutes individually to find out how they can contribute to making those actions a success. You can also participate in this. We then share our contributions. Asked them to memorize their contributions, and get back to them in a few sprints.
How large is your product backlog? I do not believe in product backlogs that are larger than what the team can handle in three, maybe four sprints. If the product backlog exceeds this threshold, the product owner might be in need of some support.
What is the typical age of a user story in the product backlog? Again, I do not believe in the value of a user story that is 5 months old. And a “but I have been working on it ever since” is an excuse in my eyes.
What is your average lead time from an idea being added to the product backlog to its delivery? No one could answer that question in the before-mentioned session. But it is actually one of only three metrics that can provide some insight on whether “agile” has been successfully adopted by your organization.
Does your product backlog contain user stories none of the current team members is familiar with? Maybe those should be re-estimated with the current team members to make sure the estimation is still accurate?
How often are you grooming the product backlog? That should be done at least once a week depending on the state of the project.
On how many user stories are you working in parallel during backlog grooming? Ideally, a team should not be working on more user stories than it can handle within the next two or three sprints. Otherwise, the risk of allocating resources on user stories that may never make into a sprint backlog becomes too high.
How long does the grooming of a typical user story take? The grooming should not be taking more than one to two sprints.
How are you creating user stories? (Is it a joint team effort with the PO or is the product owner writing the user stories and the team estimates them?) There is a tendency to observe that product owners become more a kind “technical writer” of user stories which then get estimated by the team. I suggest, however, to turn user story creation into a join effort of the whole team.
Where are you discussing user stories? Only during grooming sessions or also on Slack or via comments on tickets, for example? Every team has it own habits, and maybe commenting in Confluence, Jira, Github or utilizing Slack is an effective means of communication in your organization. As long as this happens before a user story is selected for a sprint backlog, this should be fine. Discussing its essentials afterward is a problem, though.
Do you apply a “definition of ready” standard to your user stories? That should indeed be a standard. A volatile velocity can at least partly be attributed to the lack thereof.
If so, of what criteria is your “definition of ready” composed of? Typical criteria for a “definition of ready” are: The description is available, acceptance criteria are defined, the story can be delivered within a sprint, all UI deliverables are available, all (probable) dependencies are identified, performance criteria are defined, tracking criteria are defined and the story is estimated by the team.
Who is writing acceptance criteria and in what format? It should be the product owner in collaboration with the team to create a shared understanding of what needs to be built.
How are you estimating the likely effort of a user story? An estimation poker would be useful.
Are you estimating in man-hours or story points? Estimating man-hours is betting than not estimating at all. However, I prefer user story points, particularly if the application in question is burdened with legacy code and/or technical debt. Predictability and stakeholder communications becomes easier this way as they are featured with a built-in buffer.
How are you practicing the estimation process, if the team shares different opinions? Preferably, you should observe the team’s estimation process in real life. But in case you have to ask: is it a typical vote-discuss-revote cycle? Or: when and how do you pick an estimate? (Examples: 50:50 split, e.g. 3*3 and 3*5 – which one do you take? Or a majority split: 2*3 and 4*5. Or the estimations cover a range, e.g. from 2 to 8?) It is a good way to learn more about the team building state, too.
What is a typical distribution of story sizes in your sprint backlogs? This one tries to figure out, where the commitment sweet spot of the team is, based on the sprint backlog composition. To my observation, teams often work in a more successful way, when a sprint backlog comprises of one or two larger user stories, some medium sized stories and a few small ones.
Are you re-estimating user stories at the end of a sprint? If so, under which circumstances are you doing so? That should always be done if a user stories turns out to be way off its original estimation.
What was your velocity of the last three sprints? The team should know its velocity, how could it otherwise possibly improve?
How many user stories are typically not finished within a sprint and for what reasons? If the team is bullish and picked more user stories than it could probably handled at the beginning of the sprint, so be it—nothing to worry about. Also, there are other incidents that might negatively effect the team’s actual velocity, e.g. sick leave or a critical bug a few days into the sprint. If the team, however, is regularly leaving user stories on the board because estimations were wrong, this is a sign for concern. See also: Scrum: The Obsession With Commitment Matching Velocity.
Are you changing user stories once they become an item of a sprint backlog? And if so, under what circumstances? Well, making them smaller if the team runs into a problem is certainly not great, but acceptable—if the user story in its reduced form still delivers value. Making it larger after the sprint planning is, however, not acceptable.
What are the obstacles the team is facing today?
What are the dependencies on other teams? And if there are dependencies, are you waiting for other teams to complete their tasks?
Define and discuss at least three key team goals for the project. Some of the answers may seem obvious, i.e. meet our deadline within our budget, but this discussion can often bring out other goals which are not obvious to the Team initially. It can help the Scrum Master understand Team motivations and dynamics.
What are key success factors to achieve our team goals? Defining and discussing key success factors, i.e. minimizing the impact of dependencies, can help identify project-level impediments, risks, and issues which the Scrum Master can begin to address. It also is a good benchmark to review and update as the project progresses.
What do team members hope to achieve with this project? I like to get a sense of people’s personal goals for the project in addition to the Team goals we will establish collaboratively. Having this information can help keep people motivated over the course of the project. Some people may want to learn new technologies, be part of a high-performance Agile Team, or have other goals.
What type of work environment do we want to create on this project? This question can stimulate good discussion about how Team Members want to interact with each other to achieve the project goals. Often the discussion centers on trust, communication, collaboration, and respect, but it’s good to make sure there is some agreement (or an acceptance of differences) by the team about what is important.
What can we do as a team to make sure that we support each other to achieve our team goals? This question can help the Scrum master understand how team members understand the importance of making commitments as a team rather than as individuals. It can also help the team establish informal agreements about the need for everyone to support each other, to take on roles outside their specialty, and trust their team when they need to ask for help.
What should we do when we are not achieving our goals or not supporting each other? Obviously, this can be addressed in a retrospective, but having the discussion early can be helpful to understand how team members perceive how these situations should be handled. It can help establish the need for open and honest communication built on trust.
How should we celebrate success for achieving our goals? It’s important for the team to visualize and expect success. This discussion can help the team discuss rewards that are meaningful and keep them focused on realizing those rewards.
You know, the Business Model Canvas, the Empathy Map, the Product Canvas: They all have one thing in common: Stacking up all the useful questions into one piece of paper, printable starting at A3 (or larger). Guiding the users through the nescesarry steps towards Awesomeness. (To be honest, if I would have had this brainwave before we started the meeting, it probably would have been a lot more easy to go through the process.)
So here it is, the current version of our Sprint Planning Canvas. As a team, we are still tweaking it to ask us all the right questions we need, so this is only the 0.3 version… But it’s good enough to give you an impression.
Although, the Sprint Goal is not defined as an artefact within the Scrum Guide it is an integral part of the Scrum framework. It provides an overarching objective for the Scrum Team which helps them to focus “WHY” is the team invested in the Sprint.
Why do we choose to conduct this Sprint? What is the value we seek to create? Why did we select these items from the Product Backlog and not others? How will we know whether the Sprint was successful in the Sprint Review? Those are the questions we seek to answer with the Sprint Goal and if we have no clarity on those aspects of Product Development then we are missing a key element of Empiricism, and missing a key Inspect & Adapt opportunity in Scrum.