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
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
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
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
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
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.
5 reasons why developers hate Scrum
(and why they are unjustified)
1.) Too many meetings
Refinement, estimation, planning, review, retrospective, just so many meetings and they are soooo long. "There are just too many meetings in Scrum!". Are there really too many meetings? Are they unnecessary?
While at first it might seem like there are just too many ceremonies (God, I hate this word) - especially during an Agile Transformation, when immature teams take long to conduct these meetings - they all serve a purpose. All of these meetings has a specific goal, and if facilitated correctly, keeping the participants focused on the meeting's goal, it should be effective. There is no reason to discuss a far refactoring epic during the Planning. There is no reason to spend minutes arguing about a color of a button during a refinement. Keep it focused.
You also have to take into account that - as face to face communication is preferred - these meetings substitute for a lot of ineffective communication channels (be it emails with 20+ recipients or mega-chatrooms). Not to mention that only the relevant people should attend the Scrum ceremonies. If you are sitting on a Scrum related meeting, it is because it's YOUR team's meeting and most topics discussed there ARE relevant to your work. And if your Scrum Master protects your team well, probably these are the only meetings you have to attend regularly, and nothing else.
Suggestion: Focus on improving these meetings, conduct them as quickly and fun as possible. Talk about only what matters. There is a huge difference between an unprepared 4 hours long nightmare sprint planning and a fun and focused 2 hours long one.
2.) Too much face to face communication
People are different. One prefers talking a lot, the other one wants to be left alone. One preferes live discussions, the other prefers reading emails. But all can agree that face to face communication is way more efficient than exchanging emails.
You might have chosen the software developer career, so that you can work with computers rather than people, but truth is, you simply cannot avoid human interaction in this field. So if you have to communicate, do it efficiently.
Suggestion: Just eat that frog and get over with the conversation. You can sit back to your desk sooner. Talk rather than mailing. 5 minutes call rather than 50 minutes chatting on MS Teams.
3.) Less freedom
It's one of the most misunderstood aspects of Scrum. Because it's a double edged sword. Developers do not have freedom on WHAT to do, but they get (almost) total freedom regarding HOW to do things.
Old-school developers remember the good old times when they could spend a week on refactoring and speeding up a functionality... that no one actually uses and that was never a performance bottleneck. But they could spend a week on it, because they convinced people around them that it "must be done", because it's "wrong this way".
Well, try to convince a Product Owner to spend 8+ Story Points on a problem around an unused functionality that no one ever reported. POs are vigilant on spending time only on what is actually valuable to the customer. So if you want to spend weeks on gold plating a technically excellent solution only to boost your ego regarding how great of a developer you are, well, that's probably not gonna happen, because the customer does not care about it.
Now, on the other hand you get freedom over HOW you are doing things. If the solutions you give keep the simplicity principle (no unnecessary over-engineering), no one will care how you achieved the goal. In a healthy Agile environment, you should be given almost total freedom on what tools you use, what processes your team has and how you want to actually solve the customer's problem. Yes, company standards are there, customer requirements are there, those should be set, and then your team needs to be left alone, because you know how to achieve those goals the most efficient way.
Suggestion: Try to get your head around this contradiction, whether this is freedom or not. You have to work on the most valuable thing for the customer. You can achieve that goal however you want. But you do not get a say in what actually the most valuable thing is for them.
4.) Bi-weekly deadlines
This is one that I can somewhat agree with. A good analogy is, "Why are these called Sprints? Runners take a break after sprinting. You can't be expected to sprint and sprint and sprint, without any breaks in-between." It's one of the few wording choices I myself hate in the Scrum terminology. Truth is, you are rather running a marathon, but you decide the speed you are running with. No, not even that, you are going to take an outdoor activity for X minutes, but YOU decide the pace. Walking, jogging, running, sprinting? Your choice.
So my argument here is, while you do have bi-weekly deadlines during the whole year, you and your team has to make sure that you choose a pace that is sustainable. Sometimes you go faster, then you might compensate with a bit less work. You make the commitment at the Sprint Planning, you decide the amount of work you are going to take. Make the deadlines bearable for yourself.
5) They throw your work away
"I just finished that feature last week, I did it exactly how they asked me to do it, and now, just one week later, they decide it's not good for them. I have to throw the whole concept out and start from scratch. Stupid customer. How come they can't make up there mind already in the beginning? It's like I basically did nothing for two weeks. What a waste."
Well, on the surface, you are right. But only on the surface. It is true that the customer does not always know what they want. Agile way of working tries embracing this, rather than fighting it, and Scrum also prefers quick feedback. It is actually a good thing that it only took one week to make the customer realize and rethink their need. Isn't it better than throwing away months worth of work?
And while the work being thrown away can be considered waste, it actually have been very helpful for the customer to get a working concept to play with, and realize their actual need, resulting in a product they find much more beneficial for themselves.
Work was thrown away before working with Scrum less often, but in a much bigger scale. Products with years of work, features with months of work has been flushed down the toilet. Was that better?
Suggestion: Still, you can remediate thrown away work with even better customer collaboration. Make them write the 3rd component of the User Story, get there more involved in the backlog refinement process, dare to show them the work you had done as often as possible.
more to come...
Copyright © 2019 scrum-handbook.com Gyula Attila Borsós All Rights Reserved