3

We work on a agile based methodology. As the requirements get refined in every iteration, I try to push myself 100% to finish off the tasks I have been allotted.

But somehow I never finish because the requirements keep changing, so again I have to rework on them. It gets boring by the time I keep doing it until the end of the project.

Whenever I try to put entire effort into the development, it never gets done because the requirements keep changing. The entire effort I do is only partially used and this leaves me frustrated and bored because I am doing the same stuff.

This applies to the bug fixing period as well. I mentally decide that I will fix a particular bug by the end of the day, I never be able to fix it. Because either it gets too complex or there is a tool issue or I am occupied with something.

Basically whatever challenge I take up, it never succeeds and I get demotivated and frustrated, because I am not able to do it within the specified time period.

What should I do to finish my task, so that it doesn't come back again? What am I doing wrong? What should I do to improve?

  • 6
    Even in an agile environment, you should have requirements, your 'definition of done'. If the requirements are changing too frequently, it's a problem your whole team are facing and should address, not just yourself. – user34587 May 3 '17 at 13:50
  • 4
    Have you talked to your manager about it ? – sh5164 May 3 '17 at 13:50
  • 1
    It's certianly possible that there's an organizational issue in your company where requirements are not being properly defined at the outset, but also, iteration is a natural part of software development. Particularly when bugs come up and people need to decide the risk/reward of various fixes and how that impacts the whole project. I would say there will always be a certain level of "going back over your code" in this job. – Steve-O May 3 '17 at 13:52
  • @Kozaky "The definition of done" is the vague meaning, that feature i work on has been completed. I am not sure if you mean something else, am i missing somethnig? – Gin May 3 '17 at 13:54
  • 3
    VTC - this is impossible to answer IMHO – Mister Positive May 3 '17 at 14:23
8

You've tagged this Scrum, so I'm giving the Scrum answer.

During the Planning Meeting, the team and the product owner will select items from the Backlog. These items must be fleshed out enough that they can be implemented. Any items that are not clear to the team must either be clarified during the meeting, or must be returned to the backlog and taken up at a later time.

The team and product owner agree on a set of items that will be added to the Sprint Backlog for the new sprint. Then the sprint begins. Now, the development team is in charge and they do the work. Every item is implemented according to the known requirements, tested, and delivered during that sprint. At this point, nobody can come and tell you that the requirements have changed; any new requirements will have to be new backlog items taken up during a later sprint.

You deliver all the items, hold a sprint review to show stakeholders that you've completed the work, and then invite them to talk about what is most important to work on next. This is the last point where stakeholders can change requirements. Then, another Planning Meeting happens, new work is selected, and new work is dragged into the Sprint Backlog, where it becomes the team's responsibility to perform the work again.

There are 2 (and ONLY 2) ways in which deviation from this is possible. Either someone suggests a change to requirements, has a discussion with the development team, and the development team decides to accept them, or the Product Owner cancels the sprint.

Nobody can make the team accept changes to requirements during a sprint. So if you're having a lot of trouble with this, the Scrum solution is as follows:

A) "No, we can't change requirements. The sprint has started; talk to the Product Owner, we'll pick it up next sprint." B) "Please don't bother me. If you need anything else, talk to the Scrum Master." (Optionally followed by a message to the Scrum Master that the requester is an impediment to your work.)

As a developer in a Scrum Team, you have a lot more power (and responsibility) than most people realize. Learn about it. Use it.

  • 1
    Great and concise explanation on how the Scrum work cycle should be, far clearer than most Scrum books and sites I've read. +1 – BgrWorker May 3 '17 at 14:44
  • 1
    @Gin then Erik already gave you an answer on his first point: These items must be fleshed out enough that they can be implemented. Any items that are not clear to the team must either be clarified during the meeting, or must be returned to the backlog and taken up at a later time.. If you don't feel requirements are good enough push them back, and ask for clarification. If the customer changes requirement even after writing a well made specification, then just implement it anew, as you're doing nothing wrong, they're just changing their mind. – BgrWorker May 3 '17 at 15:04
  • 1
    @TheWanderingDevManager I've seen Scrum boards with "emergency" lanes for things added mid-sprint, but those should be treated as REAL emergencies, and should never, ever, ever be the norm, as they usually make the sprint fail for some items. – BgrWorker May 3 '17 at 15:08
  • 1
    @TheWanderingDevManager "Responding to change over following a plan" does not mean that you can change things willy-nilly at any time. Once a sprint has started, you should not add to it. The point of having short sprints is that the longest you'll have to wait for that new requirement is SprintLength*2-1 (the new requirement comes up the day after planning). – Chris G May 3 '17 at 16:47
  • 1
    @enderland yeah; that's the main source of "problems with Scrum"; people not actually doing it :( – Erik May 3 '17 at 18:06
3

Another approached to your problem is to stop focusing so much on the development process. Maybe it's not well implemented, but at the end, your goal should be to satisfy your customer (and it's very hard to change processes in a project).

If your requirements change too much, it's because your clients don't know what they want. It might be because of a lack of knowledge, inexperience, etc. It doesn't matter, it also doesn't matter whose fault it is.

But they want to improve their business, and you are here to help them.

That's why I would recommand to increase your dialog with your customer to UNDERSTAND what they want, why they want it, why they want it the way they asked it.

It might be their job, but it will make you an awesome developper if you do that (it's much more fun too!)

There is so much cases in which, by being passive, you are actually creating something useless for the client just because he thought of something, formulated in a way for some reason, you understand it in some fashion: TA DA: waste.

Talk to they, ask WHY multiple time to understand their need.

Once you understand what they need, you will be able to answer your own question/issue while developing and they will be thankful for that!

1

It seems your team is not doing Scrum. Agile does not mean chaotic. You should have a backlog or requirements (often in the format of user stories). You should have a sprint of fixed length and a sprint backlog of what to do. This should not change in the sprint itself. You should have a definition of done that is easy to check. Like a list you can cross off.

What do i do to finish my tasks,so that it doesn't come back again?

As a first action, you should get your team to actually test anything they think is done. That means somebody else from the team looks at the requirements and says "OK, I tested it, I think you did well, this looks done to me." That way you will deliver higher quality and even if somebody along the chain is unhappy with it, it was a team effort. It's not your personal fault any longer.

A more long term solution is to talk about this problem in your retrospectives (they are a core part of Scrum, you have them after every sprint, right?!) and find a solution with your team.

I get the feeling you need to improve on your Scrum process as a whole. Maybe get a good book or trainer for this. And get management approval, it's all too easy to say "we are doing Scrum" only to have management continue in their ways of "this just came up, do it now!" way of management.

  • Thanks for the answer.. we have backlogs and frankly speaking it isn't chaotic in the beginning. It gets chaotic in the end,as the product owners and all others seem to wake up from their dwellings,and they start making changes. We get very less time to implement and also we make careless mistakes,for which are blamed every minute. I really appreciate the point you make "you should get your team to actually test anything they think is done." But how do i know if the output of particular feature is correct. If the requirements are very vague? – Gin May 3 '17 at 14:46
  • @Gin So when does it get chaotic? Changing requirements mid-sprint should not happen. – nvoigt May 3 '17 at 14:49

Not the answer you're looking for? Browse other questions tagged or ask your own question.