It’ about time to give the Product Owner a chance to fight back. With the help of Heiko Weltin I created a list as a base for the revenge. I hope you’ll like it:
- Create your product backlog without any prioritization. In the end you need all of the features before you can bring the product to the market.
- Only create the headline of your user stories and don’t add any additional content, even if the team asks. You can’t prepare everything for the team.
- Only use two types of priorities: “Urgent” and “Can be done later”. Anything else would be a waste of time.
- Always promise release dates and scope to your customer without talking to your development team upfront. You are a skilled estimator.
- Always add one task to a user story that keeps the team from finishing it. The Definition Of Ready (DOR) is for wimps.
- Insist in long running sprints of at least four weeks. If the team has more time, more features can be done.
- Only prepare as many stories as needed to finalize half of the sprint. The rest of the time it is the task of the developers alone to clarify the rest of the stories.
- Only meet once a week with the team and keep this meeting as short as possible. You don’t want to hang out with those sissies.
- Always answer your phone during any team meeting. Don’t leave the room as the team shouldn’t be able to continue the discussion without you.
- Never attend the daily scrum. Instead, talk to single developers afterwards. This makes it easier to build pressure on them.
What do you think? Do you have some additions to this list? Feel free to add them in the comments.
It’s about time to nag the product owner, isn’t it. Fortunately, there are plenty ways to do this. To help you in your quest to do so I created a list of 10 proofed ways to drive your Product Owner crazy:
- Five minutes before the Sprint Review is the right time to tell your Product Owner that your team wasn’t able to finish anything. It is even more fun, if this was a planned release. Transparency is for milquetoasts.
- Don’t invite the Product Owner to any Scrum meeting. He is a chicken and you are the pigs, right.
- Ignore the Sprint backlog and work on the features you like the most. Who cares about the Product Owner’s vision?
- Assign all tasks that were created during your retrospective to your Product Owner. He is the root of all evil and responsible for all the problems in the project.
- Don’t attend the Sprint Review. You already know how your product looks like.
- Never show the real product in the Sprint Review. Instead, prepare a nice and shiny power point presentation.
- Never talk to the Product Owner if you have questions about a feature. Instead, implement it based on your favorite assumptions.
- If it is difficult to establish a stable communication to your Product Owner, define someone in your team to become the so called Product Owner proxy.
- Always break your release date promises. Everyone loves surprises.
- Question everything that is in the product backlog and try to start lengthy discussions about as many features as possible. At least, that’s what your mother told you.
Try this out and post your experiences in the comments. If you have additional ideas, feel free to add them, too.
The new year has just started and it’s time for the next steps to rile your team mates. So let’s have a look at one of the activities in Scrum that can be easily sabotaged: the retrospective. Here are 10 proofed ways to wreck any retrospective:
- Keep the retrospective as short as possible. No need to invest too much time in this meaningless gathering.
- Only focus on negative events and ignore any positive things. This is the only valid path to improvement.
- Handle a retrospective as any other meeting. Sit around a table and just talk.
- Ignore the complexity of the system around you. There is always a cause and effect.
- Always use crappy material such as cheap post-its that easily fall from the walls or old pens that hardly write.
- Forgo a facilitator for your retrospectives. It is only a burden and will slow the whole “meeting” down.
- Don’t use any agenda and deliberately ignore the retrospective’s phase model.
- Directly start with defining what has to be changed in the next sprint. Everybody already knows what has to be done.
- Never check if the defined tasks of the last retrospectives were done or even had the desired effect.
- Never bring food to your retrospectives. Hungry participants will do anything to finish a retrospective as fast as possible.
What else could you do? I’m looking forward to your suggestions in the comments.
Now that the team is armed with new weapons, it is time to help the Scrum Master to fight back. If you didn’t read my first post on this topic have a look at the 10 things a Scrum Master can do to drive the team crazy blog post I wrote two years ago. Here we go:
- Get you own office, if possible in a different city or even country. Working at the same location as your team could be harmful.
- Count the number of finished tasks per team member and confront those lazy buggers with the obvious low performance.
- Try to restrict the communication with the team to Email only. You don’t want to hear their whiny voices.
- Don’t tell the team what you are working on. Transparency only applies to the rest of the team.
- Always cite the Scrum guide if members don’t stand to the Scrum rules. Continuous repetition will help raising the team’s understanding for this process.
- If a team member has a question, point them to Google. Google has all the answers, right?
- Ignore the Product Owner. It is his responsibility to create and maintain the backlog, not yours.
- Don’t attend the Sprint Review. It is a meeting exclusively between the PO and the team.
- Nurture your lack of interest about the product the team is building. This is something the PO has to take care of.
- Bring drums to the team’s office and play them like on a slave ship. Every good team needs a beat.
I’m looking forward to your additions in the comments
It’s been a long time since I wrote “10 things to drive your Scrum Master crazy” and it’s about time to give you some new weapons. So, here they are:
- Hide the SM’s beloved moderation markers.
- Play on your smartphone during the (planning) meetings, as long as they are not talking about YOUR tasks.
- Always lament about the same things but don’t change anything.
- Keep blaming and finger pointing everyone else except yourself for all the problems, you are only a victim.
- Ignore all agile values as they don’t apply to you.
- Simply ignore your Scrum Master, especially when he tries to coach you. Coaching is evil!
- Ignore the findings from your latest retrospective because you have more important stuff to do.
- Write as many things as possible on ONE post-it. Clustering is much more fun this way.
- Don’t put your tasks on the sprint backlog. Your Scrum Master is an evil micro manager. I swear. Transparency sucks.
- Ask your boss to put the Scrum values into the performance goals of every employee.
We’re very excited to announce that the new timesheet feature is now available in tinyPM 3.1. The timesheet is simple and easy to use. It allows you to log the time spent on tasks and gives you instant access to weekly reports by presenting them in a nice and clean table view. You may check out your tinyPM account right now or read on to learn more.
View and log the time spent on tasks of all of your projects with the new ‘My timesheet’ view.
Navigating your timesheet
Use the arrows to move back and forth through the weeks.
It’s easy to record how long you spent on a task. Just click the selected cell and change the value instantly. Using <TAB> key you can fill in several cells (days) quickly.
What tasks are contained in the timesheet?
tinyPM knows what tasks you’re working on and displays the appropriate ones. Additionally, the cells are marked with color on days that you’ve been working on a given task.
For an overview of your team activity, just click the ‘Team’ button. You will see a list of people you share the projects with and their summary of hours displayed weekly.
In the sidebar, there is a summary of the current and the previous month – total hours by project and options to export them.
For each project you can download a CSV file, which contains all hours entered by all users during the month. This file you may easily open in your ‘office’ application and convert into your favorite report.
You can also download a ready to print report in a PDF format.
We hope this timesheet makes time tracking easy and fast for you. We’d like to know what you think, as we plan to continue improving it, so the feedback and new ideas are highly welcome.