10

Multitasking kills productivity. Task-switching costs can be deadly. What I would suggest is to make Management aware of the costs and risks of having developers working on multiple projects simultaneously. Even if for some magical reason task-switching did cost 0 time, why would you want to finish Project A and B in ten days, when you could instead focus ...


10

I will assume that the "push" approach is not only direct, but also immediate. (Like when someone comes up to you and says "hey, Joe, can we roll this later today?"). The "pull", on the other hand, is not only indirect, providing the queue as the go-between, but also delayed. Tasks might accumulate in the queue, waiting to be ...


8

TL;DR You should use ticket trackers to track tasks, bugs, or issues. While some ticket trackers can also help with resource scheduling or tracking work items against milestones, they are not inherently good at mapping agile user stories. There are ways to coerce user stories into tickets, of course, but you should carefully evaluate whether you are letting ...


7

Look for ways to deliver limited business value initially ...even if it is not something that you can actually use. Taking your example, if you are going to accept Visa, MasterCard and PayPal, you can first implement PayPal (or whichever is easiest to implement) and then have separate stories to add Visa and Mastercard. If you are going to accept ...


6

TL;DR Respect the time box, and do "just-in-time planning." Don't do so much up-front decomposition, and rely instead on iterative delivery to provide you with an emergent design. Analysis From an agile planning viewpoint, you're doing something fundamentally wrong if your backlog requires complex dependency graphing. In particular, you're either: not ...


6

This is a great question. Many teams start with something like what you have or ToDo | Doing | Done. This may be ok, but doesn't tell you much about how your work is flowing. If you want more visibility into your process, you may want more columns, but which ones? Unfortunately, there is no "right" answer. As a PM team, the first thing you'll need to ...


5

You mention Definition of Done, and in Agile, the acceptance criteria and other user story content defines if work meets the user's needs, but often allows for shoddy workmanship. We all know we can cut corners to make things work in real-world environments. It's important to understand this has little, if anything, to do with the quality of the developer ...


5

Facing similar things in the past I combined a few solutions: Try to get all the non-urgent work into the backlog, so that it is visible and foretasted for the team. Try to get an idea of how much urgent work is still making it to the team, so you can take this into account in sprint planning. When something comes in, add it to the wall in a different ...


5

No team I ever met was self-motivated to fill out bureaucracy tickets. The question you should ask is: who wants them to count hours and why. Then find out how to solve that need. Ideally, you have a capacity for each team member and that capacity goes down when you have meetings. A person there for 8 hours per day might only have 6 hours of capacity. ...


4

Bottomline: Apply the same rule for the whole team might reduce your work but also reduce the overall throughput of the project. Sorry, you may need to threat case by case. Here's why: There's no one-size-fits-all answer for this question, as it depends on a lot of factors. You're dealing with people, and you won't have two people behaving equally in every ...


4

You might prioritize the tasks into a backlog on a Kanban board. Set a board policy that tasks are pulled by priority so that the most important tasks (relatively) are always being worked. Either assign the tasks at a daily standup, or let team members pull them into their own Work In Progress column. Limit the WIP for maximum workflow. With a daily ...


4

When a task meets the acceptance criteria, that means it's done. No other options. In real life, if a developed task meets the acceptance criteria but needs some more attention or some updates that means task is not defined well. You may need to discuss this in retrospective meetings. Possible challenges are as follows: Product ownership is ambiguous....


4

For us, "it depends". We try to take into account of whether this is, for want of a better description, "scope creep" and how much extra time it adds to the task. We're using Scrum in 2 week iterations and if a request comes through that we think we can finish in this sprint without jeopardising our commitment we accept it. Sometimes we'll say "that makes ...


4

I wonder if the issue is not so much closing off a task as poor estimation of how much work remains. It is pretty common in my experience to have progress stall at 90-95% complete.... mainly because of poor estimation both of what work needs done and poor estimation of resource availability. A better practice for tracking progress is to define something as ...


4

A couple of possible options: a] Add a status of 'Ready for test'. When transitioned to this status the issue would be made unassigned by a post function. Issues in this status would represent work awaiting verification, but not yet assigned. When a QA picks up the issue they would transition it to 'Verify' which would automatically assign it to them using ...


4

First: It's clear that your testing team is way too small. A ratio of 5:1 is simply going to (1) cause a huge backlog and (2) cause bugs to slip through. Your own project is proof of this. Even if you could prove that your 5:1 ratio is sufficient you need at least one more tester. A team of 1 tester is not a good idea because you don't have anybody testing ...


3

TL;DR A task doesn't have to be completed in the same Sprint as some other task to be considered project-related work. Dependencies and related work can be done in future Sprints. 100% of project-related work belongs on the Product backlog. There are no exceptions. Decompose your documentation epics into bite-sized stories, and then prioritize those ...


3

You want to calculate Overall Labor Effectiveness. Here is a document that discusses it: http://www.kronos.com/ads/effective/30/Kronos_effective.pdf I hate to send you to Wikipedia but this write-up shows an example of how to calculate based on what appears to be a manufacturing job: http://en.wikipedia.org/wiki/Overall_Labor_Effectiveness The overall ...


3

I don't think you can split stories up the way! The normally accepted best practice for splitting up stories is always vertical - one mini-feature at a time, not a layer at a time. Doing so should make it simpler to keep the connection, I think you are losing it by splitting in horizontal blocks of work which have no business value taken by themselves. ...


3

Plan well. But be prepared to change, if you run into roadblocks. When to add tasks to stories and how to estimate tasks? You should add tasks at the time of the Iteration Planning. The dev team should have a game plan about how to accomplish the story. In my experience estimating the tasks in hours is found to be helpful. However, it should be clearly ...


3

Maybe grouping tasks in products instead of tasks could work for you. What I am thinking is, instead of having: Design Design product 1 Design product 2 .... Model Model product 1 Model product 2 You could have: Product 1 Design Model Product 2 Design Model ... You could copy and paste the Product tasks with the dependence, making it easy to add a ...


3

A few thoughts on the question: In reality, I don't see the problem here. Frequent changes are absolutely normal for Agile. Even more, this is a part of Agile. You can't make part of product "at all". There is always a chance that there will be new requirements for this part. Second principle of agile is: Welcome changing requirements, even late in ...


3

I eventually added a custom field Verifying By that is of type "User Picker". I also added an additional column called Verifying that contains tasks that are done and picked by someone for verification. So this column was placed between "Done" and "Closed". I also added two post-functions: Done -> Verifying By - sets Verifying By to the value of the ...


3

What field are you entering the categories into? I would recommend using "component" (but using label or epic would also work) and then creating either quick filters or swimlanes for the 2 different components. This way they would live on the same board, but you can easily switch between quick filters to see only 1 category at a time. But if you have your ...


3

I've spent the last year and a half working with over twenty teams that have faced very similar issues. Over that time we've experimented with several techniques and found some that work well. First off to answer you questions: 1- Yes, absolutely train support. This is the "Bill Gates Penny" problem. The developers are paid to create new functionality, ...


3

The old saying "a picture is worth more than thousand words" is also true when it comes to software specifications. You can write multiple pages of text to describe your user interface and its functionality. The result is that the reader takes an hour to read it and still has just a vague and abstract idea in their head about how the end result will look ...


3

Pull approaches optimize for flow (how quickly tasks move from 'in progress' to 'done'), while push approaches optimize for 100% utilization (making sure everyone is doing something at all times). Let's look at an example. We have two developers, A and B, and 8 tasks, 1-8, ordered by priority. Push model: We assign 1, 3 and 5 to A as well as 2, 4 and 6 to ...


2

Allow me to offer a different viewpoint, based on the Eisenhower grid - priority is different from urgency. Task priority depends on the consequences of failure. Task urgency depends on the time remaining until options foreclose. Signing my timesheet is very high priority, but it is only high urgency on one or two days a pay period. Telling my loved ...


2

Not tried this myself, but looks like it's got more than you need, calendar and email as well as tasks (plus source code): http://bowie.codeplex.com/


2

The sense I get from this question is the degree of control the OP is trying have. Controls are certainly good but the cost of control is less fluidity, agility. At the level of assignments I infer from the question, my answer would be: ease up. Don't over think this. I think the control point is at a higher level. Assign all your available resources ...


Only top voted, non community-wiki answers of a minimum length are eligible