3 estimation units you should use
Wait, I thought if I'm using story points for estimation, then I'm fine. That's all I need, isn't it?
Well, if you are truly working in an Agile way, the further the work is away from you, the less precise units should be used. Remember, the goal is to have accurate estimations, not precise ones.
1.) T-shirt sizes for high level items
Features, epics, anything considered bigger than "one single item" should be estimated in a T-shirt sized manner.
You can assign a vague meaning for each one, eg. an L-size feature fits roughly a quarter year for the development team.
But do not convert the initial T-shirt size estimation to story points, otherwise someone in upper management will divide it with your team's velocity and expect it to be ready in 3 sprints :)
To whole point of having these kind of estimations is to give an input for the Product Owner regarding the size of these features relative to each other.
2.) Story points for User Stories
The king of relative estimation, story points in a Fibonacci-like scale.
Use it for general items in your backlog, User Stories, Bugs, Technical Debts.
Hopefully already used by your teams, if not, read about why relative estimation is superior to the time-based one.
Just keep in mind to use it properly, taking not only effort, but complexity and risk into account as well.
3.) Hours for tasks
Wait, what? Didn't you just say that time-based estimation is the inferior one?
Gotta pick the right tool for the job. When items are actually being worked on, when they are in the sprint, and you are tracking the daily work, nothing beats time-based estimations.
If you are breaking your stories down to tasks, and intend to estimate those tasks, just pick hours. You are on such low level at this point, that it makes no sense to use artificial scales.
Estimation should happen on different levels. Pick the right kind of unit for each one.
Why your daily meeting sucks
Not because of who reports to whom. Not because it takes too long.
Not because of the guy who is always one minute late.
No, the issue is that cornerstone of your daily meeting is wrong.
If you are doing it by the book, people are asked the three questions, one by one:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
In this case, you are focusing on the people.
Each developer might have spent yesterday very productive, isn't blocked, and can continue to work on something.
Still, after everyone answering the questions, whether the Sprint Goal is feasible or not isn't promptly clear.
Often, several questions remain:
- "What about that open item on the left?"
- "There is an item 99% done, only code review is left, is someone going to pick that up?"
- "That item there just got reopened because of a bug, what about that?"
- "Are we going to pick that item up on which another item depends?"
- "There are still many items that we didn't even touch, are those gonna get to Done by the end of the sprint?"
You were focusing on the people, and does not have a clear picture of the items.
Focus on the items instead of people
The goal is never to have people occupied. Not that each people can say "I was working yesterday, and I will work today."
In the end, what matters is for each item on the sprint board to get to Done, to achieve the Sprint Goal.
Nothing more, nothing less. So then why are you focusing on the people? Rather, focus on the items.
Instead of people one by one answering the questions, go through all items one by one.
Start from the right hand side. The rightmost items are the closest to the Done state. Even talk about the open ones.
It's much less likely that you miss an item, just because nobody is working on it right now.
Ask the following for each one:
- Did anyone work on this item yesterday? Did anyone managed to push it closer to Done?
- Will anyone work on this item today? Will anyone push it closer to Done?
- Does anyone see anything blocking this item? Do we all think it's still feasible to get it done by the end of the Sprint?
That is all. A simple change that can result in amazing improvements.
Simply put your focus from people to the development items.
7 deadly sins of a Product Owner
1.) You are just a proxy
I know, it's all about what the customer wants. But you cannot just act like a proxy whenever the development team has functional questions. You have to take ownership and own the product you are developing with the team.
Make sure the customer understands that your understanding of the product is crucial, and you should be able to provide answer to functional questions, instead of just being a postman.
2.) You do not involve stakeholders
The opposite of the proxy PO, the god PO. You think you know it all. You think you should not ask for others opinions, as you know the best. You think you know the market, all user demands.
If you do not find yourself doubting your senses and decisions in a healthy way, you probably do not involve stakeholders enough.
3.) You simply aren't there
The sprint planning went fine, items are on the board, priorities are clear. You are good to go. You can leave the team to work for two weeks. At least you think you can.
You shouldn't, ever. You are part of the team. Although you might have other commitments and have to scan what competitors do, talk to the customer, etc., still, your most important job should be being available for the developers, whenever they have questions. If they do not have any questions during two weeks, you might be doing something wrong.
4.) You aren't thinking in MVPs
Your product needs to scale. It has to be able to handle hundreds of thousands of users. It must look amazing. It must have the best security in the world. It must have all the fancy functionalities in the world. That email address validator there shouldn't be a simple regexp, it needs to work according to RFC. You want everything. And then you get surprised that nothing gets done in two weeks.
Are you sure you are working according to the principle of simplicity? Does that feature need to cover everything, instead of doing ONE thing perfectly fine? Does that product has to be perfect and whole to hit the market? Shouldn't you be putting your product out on the market as soon as possible to validate its need?
You should be developing Minimal Viable Products!
5.) You do not listen to the developers
You want X. The team says it's a technical nightmare and will be costing 40 story points. They can deliver "almost X" in 5 story points. But you are stubborn and you ask them to cut technical corners without yourself willing to cut functional corners.
6.) All stories are DONE, but the feature is still incomplete
The act of splitting always poses the risk of losing the whole in the process. You gotta be cautious. Make sure that the large feature you have split to several smaller stories is still intact. Is the sum of the stories still add up to complete the feature?
7.) You don't check metrics
One non-functional that you should not be overlooking. Having metrics on your application, and actually seeing user behaviour.
You might think that just "listening to user feedback" is enough, but you are missing out on the less vocal people, that might show that XYZ feature of your application is the most often used, and the one which you should focus on improving.
7 deadly sins of a Scrum Master
1.) You violate basic rules
Retrospective meetings are missing. You are assigning tasks on the daily. You determine the team's capacity and put together the sprint content instead of the developers making a commitment. Your team does not have a DoD. Sprint Reviews are just about holding the team accountable for work done or not done.
While you can be an amazing leader, and although Scrum as a framework is flexible, there are rules so basic that if you violate them, the whole concept will just collapse on itself.
2.) You are doing things YOUR way
You think 2 week iterations are the way to go. The daily should start at 9:00 AM. No breaks during the 2 hours long Sprint Planning. Your way is the one and only way the PO is allowed to manage the backlog.
These are all so wrong on so many levels. You are for the team and not the other way around. Most of the time, they know what works best for them. As long as they are within the Scrum framework and the corporate boundaries, let them pick their way of working.
Sure, you might be an experienced guy who knows the direction the team should go, you might be the master of efficient processes. But eg. just because you love Docker, you should not force the development team to use it. Rather, help the team realize the benefits of containers: portability, environment independence, configuration as code, scalability, etc.
3.) You are too aggressive in solving problems
One of the most common mistakes of first time Scrum Masters, is that they think they should be on red alert for problems and solve them aggressively. Some SMs cleverly foresee that a problem is about to happen soon and solve it beforehand. Now, I'm not saying that you should let the team make utterly wrong mistakes, and sweep issues under the rug. I'm saying, let the team recognize and solve problems on their own.
Even if you know their way might be the wrong way. Let them fail, but let that failure happen quickly. Also, one time issues might be worth getting stated, but usually not worth getting discussed to death. Just don't be a Scrum Mom.
4.) You lack empathy
You aren't a boss, you are a leader. While the developers in the team aren't your children, you certainly have to develop a similar kind of empathy towards them. Do imagine them as your grown-up kids. I firmly believe that having this mindset makes you feel much more responsible for them.
Each of the team members are individuals with different values, strengths, weaknesses. Figure out what you can do to make that person happy, confident, and by that, efficient during work. Understand their problems, understand their struggles, be happy for and celebrate their successes. Create an environment where they are encouraged to learn from each other. Protect them from outside disturbances. Lastly, don't forget to have fun. No one likes to spend several hours a day at a draining workplace.
5.) You are only coaching the development team
Many people say that Scrum Masters work with ONE team, while Agile Coaches work with ALL teams. I believe a good Scrum Master has to be an Agile Coach and be able to work with the whole organization. Scrum Masters should coach Product Owners to achieve effective backlog management, efficient backlog grooming, clarified product vision, improved story writing, etc.
Company-wise, involve stakeholders in appropriate meetings, facilitate an engaging Sprint Review. Make sure that the whole company understands Agile values, the team's way of working and how the work of the team fits in the big company clockwork.
6.) You do not understand agility
Another reason I rather refer to Scrum Masters as Agile Coaches. People focus too much on Scrum. On Scrum rules. On making sure that they apply the rules correctly. Knowing how Scrum works and using it by the book is nothing. Nothing!
You are NOT Agile just because you are using Scrum. You can have your "potentially shippable product" sitting in a Git repository for years and you still comply with Scrum. Do you think that complies as being Agile?
No wonder the "Stop doing Scrum, start being Agile!" phrase is popular nowadays. Scrum is just a tool. A good craftsman does not focus too much on what makes a good hammer, rather, how to use it. Also on what tools are best suited for each task. Are you sure mastering Scrum is your ultimate goal? Do you have waste elimination on your mind? Have you ever heard of ScrumBan? What about Continuous Deployment? Are you a Scrum Master because of your job title or an Agile Coach with passion?
7.) You are all about certifications
CSM, PSC, SPS, PSK, PAL, ACSM, CSPSM, CSP, CTC, CEC, CST, CAL, CLP, SP, SSM, SASM, RTE, SA, SPC, SGP, LMP, APSM.
No, I didn't make these up. These are all the relevant certifications you can collect at the four most popular Scrum "authorities". While I do not doubt that you can learn many valuable lessons during these courses, the scale of the business that emerged from this initially lightweight paradigm makes you question the relevancy of these courses.
5 best books on Scrum
1.) Essential Scrum
Essential Scrum - A Practical Guide to the Most Popular Agile Process by Kenneth S Rubin is one of the best Scrum books you can get. This is the bible! Despite being 500 pages long, it does not overcomplicate this simple framework. Rather, it goes into details regarding each aspect and answers even your most nuanced questions.
Doesn't matter if you are a Product Owner, Scrum Master, Developer, or a Manager of them, you'll get all the relevant information. You won't just sketch the surface! If you need deep knowledge of pure Scrum, this is the book you should get.
2.) Scrum: The Art of Doing Twice the Work in Half the Time
Scrum - The Art of Doing Twice the Work in Half the Time by Jeff Sutherland is written by one of the creators of the Scrum Framework. While the Scrum Guide might seem like it has all the information you need, that is rather like a straight-to-the-point cookbook. It's all rules and steps. It's really dry. Wanna know the WHYs as well? This is for you.
This book has amazing anecdotes, talks about the origins of Scrum, ventures into team arrangements, self-organization, waste reduction, PBI sizing and several tips specifically for Product Owners.
3.) The Art of Agile Development
The Art of Agile Development - Pragmatic Guide to Agile Software Development by James Shore and Shane Warden is another thick book and another comprehensive one. Zooming out a bit from Scrum, it views Scrum and XP as the processes that are needed to achieve Agility. The majority of the pages focus on actual XP practices, so if you are tired of reading about the theory and want someone to tell you what you actually have to do in practice, take this!
Finally software development phrases get on the table as well. Version control, releasing, managing bugs, Continuous Integration, Test-Driven Development, refactoring. Concepts every Agile team must understand and use during the daily practice, yet neither the Scrum Guide nor the Agile Manifesto mentions them. This isn't (just) about the theory, this is practice.
4.) Agile Estimating and Planning
Agile Estimating and Planning by Mike Cohn is a specific guide regarding estimating, planning and scheduling. Give it someone who still believes that being Agile means no planning. You have a goal. Moreover, you have several goals with varying timelines. You want to know how to get there, when will you get there, what Value you will gain, how to execute the whole journey, and when to alter your plan.
The book starts off by discussing the usual pitfalls of plannings, then details estimation techniques and practices. At the middle is my favourite part, discussions about Value. Still to this day, too many people focus on effort, instead of focusing on Value. Everyone estimates effort, splits stories based on effort, plans based on effort, etc. while Value, the other part of the "priority" equation gets ditched. The closing chapters on scheduling and monitoring will help you getting and maximizing that Value.
5.) Agile Retrospectives
Agile Retrospectives - Making Good Teams Great by Esther Derby and Diana Larsen. You know that retrospectives are the cornerstone of evolving as a team, but lack the ideas to bring the best out of your team? With this book you can breathe life into those stale, boring retros, reveal impactful points of improvement and define meaningful actions.
The initial pages will guide you regarding creating a positive environment, structuring the meeting and some "people stuff" you might not be aware of, such as group dynamics, then comes a huge list of actual activities you can perform to gather insights and figure out actions.
Copyright © 2019 scrum-handbook.com Gyula Attila Borsós All Rights Reserved