Things that developers frustrating about

I found in my LinkedIn feed a post by Roman Frolov containing a list of things that developers are frustrated about. Here I will briefly describe how I manage these problems in my team. I hope, it can be a good conception for all of you who have similar issues.

Tasks are too big

Every story which goes to the development covers a particular feature. Only one. This is a Minimal Viable Feature, it should not be bloody sophisticated but must provide the functionality which can be used once it will be released.

No time for refactoring

In our teams, we have improvement lists, which collect our tech debt and thing that should be improved. Every month we discuss them, prioritize, and that’s very important to take them to the backlog.

Frequent priority changes

Here is pretty straightforward. We’re using sprints and backlogs where we’re collecting stories in the prioritized stack. That will prevent new stories for at least one or two sprints. Only one thing that you have to understand, if you are working for a startup you must be okay with pivots otherwise I'd suggest taking a job in a slow and big company group.

Too many tasks in progress

It can be a bunch of reasons why. First of all, check that you use TDD to decrease the return of stories from testing to development. Then check, that everything is clear before a developer takes the story for implementation, and organize grooming meetings for that. Don’t be afraid to return a story to the backlog or groom it many times before every small detail will be written down in the story.

Task descriptions lack details / Telling “what” to do without explaining “why”

I met this problem many times. And really, developers can receive the task containing a title only. It happens even in big companies. Such a shame for those product/project managers and scrum masters. Therefore I collect my minimal requirements for how the story must look like.

So, every story should at least have next sections:

Why?

The most important section explains why we do that. This section is key for successful and optimal implementation. Nobody except developers doesn’t know the system so well, if they will understand why they have to implement a feature they suggest the best way to do it. At least from the technical perspective but sometimes they can improve the business side as well.

What to do

This part describes exactly what should be done. Might be a new web page that must be added, what must be represented, and how should it look like. Attach here everything that can help the team deeply understand what are you expecting, how the feature should look like, and its functionality. This is section is not carved in stone. During the grooming meetings, you have to add there all details which will be clarified after the questions will be answered.

How to test

It can be a section containing linked Test Cases in TMS, or plain text Text Cases in Story or BDD. But you have to provide inside the story the main use cases in the form of test cases. It helps team members to understand requirements and will increase velocity by decreasing the number of returns of a story from the QA to development.

Results

A checklist contains everything that must be done during the work in this story. DB migration is needed? It goes to this list. Any documentation in any form should be created or updated? It goes to this list too.?

I hope my experience helps you to motivate your team and by following these principles you make your team members happier or keep them motivated.