Meet Ms. SWAT-i, a Product Owner (PO) for whom everything is a fire-fighting operation. She handles everything as a SWAT team operation, often at the last moment.
Anti-patterns
Ms. PO, you want to ensure your team fails? Use some of these anti-patterns 🙁
Not being available to team. An absent PO is a sure shot to failure! Even a high performing team can not mitigate this.
Absolutely no knowledge of the business domain!
Focus on yourself (CYA, how I keep my job) rather than focusing on Customer
Unclear about the backlog items. Not having enough information, not having answers for the team when they ask for clarification.
Focused on just the early wins, low hanging fruits! [You should be focused on HV,LE items (High Value, Low Effort) ]
PO who is tied down to a chain! A PO who is not empowered is a sure shot to delays and confusion.
Asking team to start driving without telling them where you want to go. Even worse would be for PO to not know where she wants to go (anyone heard of the Vision statement!)
Over committing to your stakeholder (sucking up to them!?) without consulting your team.
Say ‘Yes’ to every change that comes your way. Say ‘Yes’ to all the requests from your stakeholders and pushing them to ‘in-flight’ sprints
Play musical chair with your team in the sprint! Keep changing priorities even for those stories within your sprint.
Doing the product owner role by committee! (Trying to keep everyone happy in the stakeholders community)
Instead of being a bridge between dev team and customers, stakeholder community, get them into pissing contest, having them pointing fingers at each other. It’s more important to find someone to blame rather then delivering value!
Sounds familier?
Is any of your PO exhibiting these behavior(s)? Run as far as you can from one if you have!
In the next post, we will meet another PO, Ms. Fab, who is polar opposite of Ms. SWAT-i. She will show you how the PO can create VALUE for you, your team, your organization.
Daily Scrum or Daily Stand Up is a very important ceremony in the Scrum framework. As part of the Daily Scrum, the team meets on a regular basis for a quick sync up of 15 minutes.
Scrum Calendar Events [DS=Daily Scrum]
Remember, you only have 15 minutes to finish this Daily Scrum. We want to use every minute optimally during this ceremony, don’t we? So what are the different ways we can optimize it?
Top 10 Tips for Daily Scrum
Here are my tips to have the team gel together quickly, as well as eliminate unnecessary churns that will happen at the Daily Scrum. Again, the goal is to maximize every minute of this Daily Scrum and make it a high performing ceremony.
Come Prepared
Ask your team member to use this tool before they come to Daily Scrum. Have your team members think about their updates before they come to Daily Scrum. Write three things on the Post It notes.
Write your updates to the three basic Questions
Be Explicit
Announce the start and end of your Daily Scrum. Make it explicit, use some specific music or it could be a simple as some one just announcing that it is the ‘START’ and ‘END’ of the Daily Scrum (at the beginning and end of the 15-minute timebox respectively).
make it Explicit – Announce START and STOP
Parking Lot
Introduce Parking lot and use it extensively to defer the discussions (after the end of Daily Scrum). This will help you keep the momentum during the Daily Scrum and enable you to quickly go through the synch up from each team member.
4th Question
Introduce 4th question: Is there anything that you want to discuss with your team member(s) after the Daily Scrum?
4th Question – Defer to Parking Lot
If yes, the team member mentions it quickly and someone captures it into the Parking Lot. Review and discuss the items on Parking Lot after the Daily Scrum is completed.
After Party
This is a time set aside, allocated for the discussion that we deferred during the Daily Scrum. You may have put a couple of items in the Parking Lot. Once the end of the Scrum is announced, some of the team members would stay back for their respective discussions. This is what I refer to as to as After Party!
All the team members do not need to stay back, only the ones who are required for the discussion would.
Just have proper equipment(s) to provide better quality audio and video to the team members.
Yes, the Daily Scrum has to be in person. And team members have to be there physically for the Daily Scrum. With that said, there will always be some exceptions where a team member cannot attend the Daily Scrum in person. You will have to have a way for them to remotely attend the Daily Scrum. Having better quality audio will tremendously improve the productivity of your Daily Scrum.
You need to cover those exceptions (as discussed in Tip# 6) in your working agreement, have the team talk about it as to how they will handle those scenarios where a team member cannot attend the Daily Scrum in person. Amend your working agreements to cover that scenario.
For example, one of my team had this on their working agreement:
When a team member cannot attend in person…
S/he will provide the updates to his/her Buddy. This buddy will bring those updates to the team in person.
If that cannot be done then the team member will jump on the conference call.
When everything else fails, send an email addressed to the team with your updates.
Bottom line is to have your team discuss these scenarios and update their working agreements accordingly.
Break the eye contact
I have seen this time and time again, especially with the new teams. Often times when providing the updates, a team member is looking at the Scrum Master (only) as if she is providing the updates to the Scrum Master and not the team. Now, remember Daily Scrum is for the team. A team member is providing the updates to others on the team, not just to the Scrum master. To break this mode I often encourage my Scrum Masters to break the eye contact. As soon as a team member starts providing updates to you as a Scrum Master, look away from her. Look at the floor or look at your scrum board; do whatever to break that eye contact. This will encourage them to look at other team members.
Be Absent, intentionally
I encourage Scrum Master to occasionally skip the Daily Scrum, be absent intentionally.The goal here is to see how the team handles your absence. Does the Daily Scrum break apart because you are not there or does the team step up and handle it nicely.
This will also give you indication as to whether the team is self-organizing and tackles those scenarios by themselves
Make it Visible
The last and the most important tip I think is to make it Visible. As they say, a picture is worth a thousand words! So, use all the visual props, you can use a wall in the hallway as your Scrum Board, or use some flip chart papers and start using that as your Scrum Board.
Put your posters on that and use it while having the Daily Scrum. Post your Working Agreements, Definition of Done, and Definition of Ready in the Daily Scrum area. In short, make it visual!
As I mentioned, in the beginning, these are simple techniques that I have used a lot when I start working with new scrum teams. I often introduced this in an incremental fashion. They are very effective and impactful.
What tips are you employing to keep your Daily Scrum on track, to finish it on time while keeping it useful and productive for the Team?
Let us know and we will include it in this list, along with credit to you of course.
Write better User Stories with this Visual Worksheet
User Stories are the lifeline of an Agile team. Even the BEST, high performing teams will struggle to deliver Value if they are fed bad Stories. As they say, INVEST in your User Stories!
Use this visual worksheet to help you, guide you in writing better User Stories. Help your team Help you with this worksheet.
Onwards to writing user stories that help teams in creating value, frequently and on a regular cadence.
Sprint length to shrink or grow. Jen, one of the Scrum Master I am coaching and mentoring asked recently:
I am scrum master for this team and generally, we do two-week sprints. But, for this sprint the team does not have enough work, so they want to shorten the sprint from two weeks to one week. Can I allow them to do that?
Now, let’s ponder on this question. Take a minute and think about it. What would be your answer? Why?
To answer her original question, I said a big resounding NO! In bold capital letters!
Value of regular Heartbeats
There are many reasons for not allowing the Sprint to shrink or grow. We want the team to pick a sprint length and stick to it, no matter what. Instead of focusing on why we do not allow it to shrink or grow, let’s focus on the positives. Let’s review the reasons and value of staying on the same length. Keeping the sprint length same provides:
Consistency and a Rhythm for the team
Repeatable and Predictable Cadence
Consistent length provides valuable data that can be used for forecasting
Schedules that are known well in advance, and can be put onto calendar to help block time on key players calendar
Valuable data they can help team in deciding how much or how little work to take into next sprint
Don’t flush them down the toilet
There are several measurements that are linked to sprint length. Measurements such as:
Velocity
Say: do
Story burn-up
Release burn-up
Feature burn-up
You allow your sprint to shrink (or grow) and you are invalidating all the data, you are essentially flushing all these down the toilet!
Use it Wisely
If you have a situation where the team does not have enough work for the next sprint, it might be an indicator of the team not doing backlog grooming; or at a minimum, it is an indicator that the backlog grooming is not done properly.
In a scenario where the team has spare capacity, instead of shrinking the sprint length, the team could do other, very useful activities. They could use that extra time on:
Refactoring the code
Learning new stuff
Cross training within the team
Automation
Spike or research on the next priority features functionality
Experimentation
Sprint’s are fixed length. Scrum does not allow them to shrink or grow. Once the team agrees to a specific length, they have to, rather, they need to stick to it. Fixed length eventually will enable them to settle on a rhythm giving them even heartbeats!
mentorME
We offer mentoring and coaching to up and coming Agilists; often time doing 1:1 coaching. If you want to grow in the agile space, if you want to expand your horizon, if you want to learn the tools and tricks, sign up for mentorME.
Got more questions? Please get in touch with us here.
When was the last time you looked at the burnup chart? This burnup chart draws a good portrait of how the team is handling the work and creating value. Are you worried that your burnup chart is morphing into a Hockey stick? Go ahead.. grab a copy of the burnup chart!
Burnup Chart – Hockey Stick for an individual sprint
Burnup chart-Hockey Stick for a release
Burn up chart-Stepping Stone-for a release
Let us pause for a moment and look at your Story Burnup chart. This chart can take on many forms, as beautifully described by ScrumDesk in this article. How does it look? Does it look like a straight horizontal line (showing no progress)? Does it look like a Hockey stick as depicted in the two charts above, or Stepping Stones as depicted in the last chart? Or, perhaps, in between!
You have to pay close attention to this chart on a regular basis. The Story burnup chart can tell you a lot about your teams’ mentality and mode of operation.
If your chart looks like a hockey stick, then it is telling that the teams are scrambling to close the stories and burning midnight oil. This hockey stick can hurt you, a lot!
Quality is the first one to take the hit!
It hurts you in multiple ways! To begin with, I would question the quality of work completed (or at least, marked as completed) as a result of this 11th hour scrambling. Apart from quality, you have several other issues such as:
overworked team members
frustrated teams
frustrated business and Product Owner (PO) becuse they are not getting what they want. They are giving acceptance at the last minute and not satisfied with the quality
dejected, demoralized teams
Burnup and Root Causes
There are several reasons why your Burnup morphs into a Hockey Stick, such as:
Team members working in silos
having too much stuff open or too many User Stories open and in progress,
The team is spread too thin across many User Stories, too many balls in the air!
Team not clearly about the end state for the stories. Do they have Acceptance Criteria listed?
This hockey stick is an indicator of poor quality (or absence) of Backlog grooming activity.
Product Owner (PO) should be able to give you clear Acceptance Criteria. You can also focus on improving the quality of backlog grooming sessions, to come out with better stories, with better understanding of the functionality sought and the end state, the validation criteria.
Red Pill and Blue Pill
The hockey stick chart also suggests that there are lot of delays in closing the stories. These delays could also be caused by impediments not being reported or not being worked on agressively. Trade this hockey stick for stepping stones that lead you to the top line!
If this Hockey stick is so painful for the team, then what can we do to change it to turn into more favorable Stepping Stone chart (on the right above)? We can approach this in multiple ways. Below are the Top 5 ways you can prevent your burnup chart from morphing into a Hockey stick.
1. Change the question
It starts with mindset change, shift in the thinking, shift in the way team approaches the work. We have to shift our focus from completing tasks to completing and getting acceptance on the User Stories that deliver Value to our customers.
(Accepted) User Story = You serving up slice of VALUE to your CUSTOMER 🙂
If we tweak the questions a little bit, it will help us shift the mindset. At the After Party (after Daily Scrum has just finished), ask the team: What stories can we drive to completion and Product Owner Acceptance? What is stopping us from getting acceptance on the stories?
This will help you shift the focus to completing the stories. As you discuss this at the After Party, ask for volunteers to own and act as steward for individual user stories. The steward is someone whose primary job is to continue to drive that user story to PO acceptance.
2. Story Swarming
Encourage the Story Steward to use Story Swarming to drive the story to completion and acceptance.
Swarming: A small teamlet, smaller sub group within the team to swarm on the story and drive it to acceptance.
Remember, just completing story is not enough, you want to get PO acceptance on them for you to mark it as DONE.
3. WIP limits:
Ensure that the WIP limits are adhered to, and adjust WIP limits (with team’s consensus) that ‘forces’ team to focus on User Story acceptance, before that start working on another story.
Restrict your team to few stories open at a time and challenge them to finish the story before they start working on new one. Ask them to stop starting and start finishing!
4. Visible Progress (or lack there of)
Above all, make and regularly update the Story burnup chart. This chart can be an invaluable tool for the team to showcase their progress. Make it visible to the team, and discuss it with the team at a regular frequency. Even if you are using electronic tool (such as Rally or Version One), ensure that you have a printed copy of the chart displayed prominently to the team.
5. Impediment List
Encourage team members to report any impediments as soon as they are known. Keep a running list of these Impediments, and aggressively work towards resolution or alternatives to ensure that the team can continue to make progress. Make the list itself visible to the team, as well as the progress being made on resolution of them.
These steps will help you slowly bend the hockey stick into the shape of steps leading you towards the top line. It is a chart that shows that team is getting small number of stories accepted every few days during the sprint. It is a proof that there is no 11th hour scramble. It’s a proof that team is swarming and working collaboratively towards closing the User Stories.
Not being available to team. An absent PO is a sure shot to failure! Even a high performing team can not mitigate this.
