0

7 Deadly Sins of Project Managers & Scrum Masters

Guide for non-technical people in charge of managing IT teams to understand the needs of programmers better.

1. Use Templates

In order to stay consistent across the project, choose the template for your Issues, bugs, and PRs.
Please check this resource.
👉 Github Templates
they have plenty of good template examples.

2. Catch up with a Technical Jargon

Whenever you are working with a Frontend Developer, Designer, or even a Backend developer, catch up with technical jargon and terminology. Every app element has its own name.
For example:
Tooltip is not a “cloud” or “that box“, you don’t need to call me to show hover functionality only because you don’t know it is called “hover“.

That said, here is documentation of bootstrap:
👉 Bootstrap Documentation
It is a good start!

3. Don’t Call Me Too Often

I really hate when somebody disturbs my workflow and breaks my focus. Not every information has to be consulted via call. Use direct message instead, include screenshots, etc. Keep calls sacred and leave them for urgent matters only.

4. Create Better Tickets

Besides making tickets clearer by using templates, you can also use checklists with all the requirements. It is way easier to read.

Include designs/resources and link them directly to the ticket. Once I had a situation when I used old designs because of that and wasted a week.

About the description itself… When you include designs, you don’t need to be so specific about what goes where. For example, “Green button should be included, there should be input with name, there should be input with the last name, there should be input with age” – Those things are obvious from the designs.

Instead of doing that, try to describe parts that are not obvious like:

  • Is there any special validation in these fields?
  • What are the error messages?
  • Is there any pop-up notification after successful submit? Where do we redirect?

Set deadline/milestone/labels

Whenever you create a bunch of tickets, set up the correct deadline, milestone date, or priority label. We are working at our pace. After finishing the ticket, we can take a look at a ticket board and choose the one that has the biggest priority. We can avoid many unnecessary chats about what to do next.

5. Definition of Done

What is a definition of done?
It is an agreement between The team on when the ticket is finished.
Why is it so important?
To avoid unnecessary back and forth with a ticket.

For many managers, I met a finished ticket means: “it was working when he showed me.” They don’t understand that besides the feature “working” developers needs also to write some tests, take care of refactoring.
Making a document with a “definition of done” ensures that non-technical team members understand the process of building good software. You will be able to communicate better and improve your workflow.

6. Tickets Estimation

Don’t change ticket requirements after estimation.
How many times did you show your finished version of the feature, and you had this conversation?


PMLooks good, but can you add this X, Y, Z?
Programmer But it was not in the requirements!
PMLet me edit that
*Adds 3 more tasks*
ProgrammerAt least when you do it, change the estimation!
*PM Increases estimation*
Programmer – And I suppose to do all the other tickets that were plan for this sprint
PM – YES!

I had this conversation many times…
Please create a new ticket, or adjust the whole sprint whenever you want to add something new. If it happens once in a while, it will be okay, but this can quickly turn into a habit and definitely mess up your sprint and put additional stress on developers.

7. Meetings, Meetings, Meetings…

So many meetings seem unnecessary. You could send an email with all that information.


Make differentiation between extremely important meetings and the ones that could be avoided. I always ask myself before setting up a meeting if there is another way it could be solved. After I know the matter needs a meeting, I’m making sure to invite only relevant people. I would even ask people directly if the meeting would benefit them or schedule the agenda so that people who need to be there for 5 min to discuss one’s matter will not spend 1h with everybody just sitting and killing time.


Keep your meetings short, around 40 min. Maybe some people can keep their focus longer, but for me, I tend to zone out if the meeting is getting too long. Having Agenda helps a lot, you stick to the timetable, and everybody has in mind the topic of each meeting segment. That way, you can avoid any irrelevant discussion.

👥 Follow me on the Social Media 👥

Programming Struggles

Leave a Reply

Your email address will not be published. Required fields are marked *