What should we do with a task that has been blocked

Question

We're using Agile and Scrum methodology.

For this iteration a coworker had to finish her Development task, which was carried over from last iteration. We thought it will be done in two days and we can start black box testing on it. So we had two tasks: one assigned to her for finishing up the development and one assigned to me to run black box testing on her project. But her task almost took the whole iteration - one day left - and obviously it is impossible for me to do my task now.

So what do you think? What do I suggest to project manager? I do not want my name to be on a task, that for the whole iteration I have been blocked from doing! We can still partially finish like 3 of 20 of those test plans from that task, but definitely not all of them at all.

Answer 1

Development task which was carried over from last iteration and we thought it will be done in two days

If the task got carried from last iteration, then I would say that the task is too large and it should probably be re-analysed and broken down into smaller tasks. You are now looking at a single task running over two or more iterations.

her task almost took the whole iteration - one day left - and obviously it is impossible for me to do my task now

There might be a lack of communication here. I find it alarming that you are saying this a day before the end of the iteration. Do you already have a test plan in place and you are saying that one day isn't enough to test the feature, or do you not have a test plan yet? Our tester normally raises such an issues three to five days before the end of iteration.

what I suggest to project manager? I do not want my name to be on a task that for the whole iteration I have been blocked from doing it!

First point I'd like to make is regarding impediments. If you knew that you were impeded by an "unfinished feature" on Monday, then I would state this to my project manager or senior developer on the same day. We have a whiteboard where we write down our name, date and time as well as a person or a third party that we are impeded by. So you could make this clear few days before.

A member of team keeps a track of impediments and analyses them on a weekly basis. This allows them to explain certain holdbacks to the business and make improvements within a team.

Developer should have communicated with their team lead or project manager and make them aware that they are behind. At some point we were running SCRUMs and what we had to close X amount of hours per day. Say I have a task estimated at four hours, and I spent eight hours on it already. Project manager would then run statistics on daily basis and after few days it would be clear to the PM that I'm running behind by 20 odd man hours. So I can say that PM is equally responsible for this.

we can still partially finish like 3 of 20 of those test plans from that task but definitely not all of them at all.

Now this is probably the most important point. Three out of twenty is 15%. Assuming all your tests pass, you'll be at the most, 15% confident that feature is working. Would you drive a car if you knew that breaks work 15% of the time? You see the point I'm trying to make.

I would personally recommend not to release this feature, gather relevant team members and get some feedback prior to making any changes or going into next iteration. You need to find out what's going wrong and fix it.

To summarise, I think that multiple people are responsible for this issue, including project manager, developer and yourself. This is based on my experience as a software engineer, not a project manager.

Answer 2

Your question suggests several Scrum smells:

1. If your colleague was working on a single item and it turned out only at the end of the sprint then you are doing something wrong. I strongly suggest to bring this issue to the team and spend some time finding the root cause during the retrospective
2. If you are doing Scrum, then you shouldn't worry about your name being on a task, because the shared responsibility it is not only your problem, it is a team problem. Again, a great retrospective material
3. In Scrum the Scrum Master should talk to the project manager in situations like this, you are safe

We had problems like your all the time and our solution was to stop doing everything else and put focus on the blocked issue as a team. Of course, there are cases when it is impossible to work on a task with 7 people. In that case, the rest can help out with those item which were interrupted by the blocking item. Even if you are not finished before the end of the sprint, you did everything you could in order to solve an issue. If you improve yourself so that this won't happen again, then you are agile.

Back to the Scrum smells: spend some time solving those issues, because they will happen again, and the later you solve them the more painful it will be.

Answer 3

Lots of different things could be tried to improve this in future iterations. My answers are more in questions since we don't know the specifics of your team, technology or culture.

Swarming - Why was there only one person on the task? Is everyone working on individual tasks that are separate. How about trying a couple of people on one task. Especially if they are taking multiple days

More granularity - I like to give teams the goal of breaking down tasks into things that can be accomplished in no more than a day. This way we are checking things off every day. Many believe that the more granular your tasks are the more predictable you can become with scrum and kanban

Pair programming - should there have been two people? Was it a touch technology or part of the code that having two people on would have reduced the risk and delay?

Retro - what comes in the retrospective for the sprint? What action items did she come up with for next time

Team Effort - each feature is a team effort. are you helping each other reach the finish line or only concerned with what is assigned to you? Are you assigning out individual tasks in planning? What if you picked them up during the sprint and drove each feature to completion with some of the suggestions above.

Good luck!

Answer 4

This answer may be more from a development perspective, but building software using object oriented techniques and MVC can also help dissolve issues such as this.

You and your coworker should have taken 30 minutes to spec out what the output from her part of the project would look like and what your input would look like. You then write stubs that simulate hard-coded output from your coworker's module. This means you can work on your part of the project and work up to the point where your coworker is complete with her part. Then you integrate the two pieces.

Without knowing all the details, it's hard to give you a solid answer, but even if you were working on frontend components, pieces of the UI can be stubbed out and hard-coded data can be used as placeholders.

This concept is of course a lot more successful if you follow Erin and Danny's suggestion to break things down into more granular components. Not only does this make it easy to develop independent modules, but also it makes it a whole lot easier to test those components.

Answer 5

When you are using Scrum, you should be using "cross functional team members" to develop vertically - the testing of a user story should be a part of the user story.

If the user story is broken up into smaller tasks and the tasks are dependant, then putting them in the same sprint can cause delays.

You could break up the black box testing into smaller testing tasks, then complete a few of them in this sprint and postpone others to another sprint. However, it may be better not to commit the code behind the original task to the integration branch if you feel it has not been tested enough. (Does it have white-box unit tests?)

Answer 6

I think you have a bigger problem than the particular task blockage scenario. If a task was blocked for so long, did it come up in the daily scrum and did the Scrum Master do anything to remove the impediment? If the external dependency was not possible to remove, the team should be updated and there should not be any concern on why your dependent task could not start. Also, the very discussion of individual responsibility and you-vs-me mindset is contrary to the team ownership that Scrum promotes.