Problem of completing assignments overdue

Hello. I am a software developer. I have a problem in which I complete my assignments constantly overdue. Can somebody suggest how I can tackle this issue? Thank you in advance.

Start earlier or do them more efficiently. General advice, but you didn't ask anything specific.

How are the due dates determined?

A bit more on that.

If you are talking about university assignments, another general advice is, to read assignment instructions right away once you get them, so you could get an idea how much time you'll need to accomplish it.

If you have pretty good idea how long (approx) will it take for you, then you just start at the right time in order to finish on time

If after reading assignment instructions you don't have an idea how long will it take for you, then you start right away until you get better idea, then you see if you have a buffer of time and then you do whatever you want with that buffer

So that technique falls under "start earlier".

Other technique is do them "more efficiently".

Now, that can mean different things to different people. For me that used to be, do the things in undisturbed and undistracted environment. Meaning, TV off, phone off, snacks off until you make some tangible progress. The more progress you make in one go, the easier is to come back to task other time, because every time you have a clearer picture of the end goal.

Others may say, don't try to get everything perfect right away, get something working, adhering to requirements end-to-end, then as the time permits refactor/polish until you get closer to the perfect, and depending on time, you do what you can.

Thank you for the advices.

Yeah, I was not specific. The problem that I have is my JIRA Stories tend to keep moving to subsequent Sprints.

Stan Belen wrote:The problem that I have is my JIRA Stories tend to keep moving to subsequent Sprints.

Well, either your stories/tasks are too big for the sprint to complete or you work too slow. Also clarify what is your definition of story? Asking this, because I saw in multiple occasions people use these interchangeable, say story, but mean task, and other way round.

The idea is, you shouldn't have tasks or stories that could not be completed within the sprint, and given (I'm assuming) you work as part of the team, before you get task into the sprint, you should get an agreement as a team that such task IS completable. Otherwise need to decompose them more, so they are smaller.

Anyway, have you discussed this with the team first? What they say? What your tech lead says?

I think the problem may be because of the following.

The only meetings that we have as a team are:

1. A morning scrum, in which we tell what we did yesterday and what we plan to do today

2. A planning meeting for the beginning of a sprint

3. And a meeting for the end of the sprint

In the scrums we talk on a high level. It feels for me like I work on a task in isolation and I often steer in the wrong direction the implementation.

I want to advice if the following would be a good idea:

I'm thinking to tell my manager that I think that it would be helpful if the team can be divided into groups that are working in the same area and, in addition to the scrum, for these teams to have a separate meeting to discuss their work in more detail among each other. I think that this would make it much more helpful, to share how you are implementing something and bounce ideas, get feedback, etc.

Do you think this would be a good idea?

Absolutely no one has ever accused me of incompetence, but I have taken a lot of static for lack of speed. My preferred projects tend to be mission-critical, so reliabilty, performance, and security are important to me and those things take time to get right.

I didn't have as much pushback during the mainframe era. When you can single-handedly take down a multi-million dollar computer system with hundreds of users, they tend to understand. However, the PC era has encouraged sloppiness (You can't just "turn it off and back on again" when dealing with a mainframe). and the false idea that first-to-market always wins (remember the Palm Pilot and Apple Newton?) means that "Git 'er Dun!" is the common order of the day. Quality be damned.

It's also worth noting that a common conceit in IT is "All You Have To Do Is..." and thus, any goal is obtainable quickly and with minimal skills. This failing afflicts not only Management and Users, but also developers themselves when it comes to estimating time requirements. My preferred estimation approach is to consider how long I think it will take, triple it, and with luck, get it finished in 2/3ds of the estimated time. But that only works when you aren't dealing with people who insist on their "AYHTDI" estimates and won't go with your own. And just like growing apples, there is no "Art of the Deal" when it comes to time spent. It will take as long as it will take, and you can't force it to be faster (although too much meddling can make it slower). And, for me at least, the real time-killer isn't that tricky interface to that wonky server or whatever, it's the 3 days I spent looking for a single mis-placed comma. It happens every time.

So you have 3 options.

1. Work with management to get more realistic estimations.
2. Learn to work sloppy and just "Git 'er Dun!". After all, it's not your name that will be printed in the news when the company's customer info ends up for sale on the Dark Net.
3. Find a more realistic employer.

But just to make certain, consider whether you do, in fact, spend time worrying over things that aren't worrying over. If that's slowing you down, you need to learn to be more confident in your own work. Optimising your time is just like optimising code. Don't optimise things unless there's an observed need for optimisation and spend your effort on the things that do.

Stan Belen wrote:I'm thinking to tell my manager that I think that it would be helpful if the team can be divided into groups that are working in the same area and, in addition to the scrum, for these teams to have a separate meeting to discuss their work in more detail among each other. I think that this would make it much more helpful, to share how you are implementing something and bounce ideas, get feedback, etc.

Do you think this would be a good idea?

I'm not sure how your system/services are structured, but if you are saying something similar that Backend and Front-End teams are mangled, then yes, potentially would make sense to separate them.

Now, as far sharing knowledge or discussing the implementation details, give a try pairing with someone on the aforementioned task(s). Two heads usually are better than one. And that is also good for knowledge sharing.

Over the years observing those things in the teams I worked with, I feel your tasks aren't decomposed enough or in different words - too big in scope, hence could not be tackled in reasonable amount of time.

As an example what I mean, let's say you have a task to implement some API endpoint, that consists of (taking example from a thin air):

produce OpenAPI specs

create database table(s)

implement API specs

So now you have couple of choices, you can have a one task, or you can have three tasks, likely tackled in different sprints. So when you do this kind of repetitive work several times, you start getting a pretty good idea how long each of those tasks take. After few iterations like this if your team no longer sees the point in decomposing that much, you have it as a singular task, but now you can be more accurate in predicting the time it may take.

And I believe that any big task could be decomposed to smaller set of tasks, then those smaller tasks into more smaller tasks until they are manageable in terms of scope to achieve in a reasonable amount of time.

Another thing what I think helps, if you work on tasks and constantly get stuck on something that makes you delay in accomplishing them, maybe you don't do enough discovery around the area, so you have too many unknowns or fuzzy areas that surprise you during implementation.

So to deal with this kind of things, you maybe could have some discovery tasks prior actual implementation where you could give a go in some dirty way to get a sense what you are going to deal with and later just discard that work, so the upcoming sprint you could work on actual task implementation, but now with smaller chances to surprise you.

But you know, there is no one silver bullet, you need to experiment and see what works for you and your team.