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 ...


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 ...


8

Quick answer - task priority is determined by the order in which tasks have to be done to achieve the goal. Longer answer - Going along with David's comments, I don't see where one task would be of a higher priority than another. This is going on the assumption that, if it's in the plan it's something that should/needs to be done, therefore it's equally ...


7

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 picked during the day, or ...


6

When you think about it a bug tracker is nothing but simple task management application with (a simple) workflow attached to every item. From this perspective it doesn't really matter whether a work item is a software bug, a task to perform or anything else. It means that you should be able to use bug trackers to achieve the goal you define. I was ...


6

I prefer creating a new story that then goes into the backlog. The story is usually something like: "When using [feature we created in current sprint] I want to be able to do [x]" Notice that I said it goes into the backlog, and not necessarily into the next sprint. Its something new, and needs to be prioritized against everything else already in the ...


6

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 ...


5

If you are following Scrum then there are two options: The Product Owner terminates the sprint and the modifications are reevaluated and new user stories are created The new ideas become user stories for the next sprint Additionally, I suggest a retrospective about the issue, because how come that the new ideas are not known at the planning meeting? It ...


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

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 ...


5

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 ...


4

Before going into a system that offers the segregation between a task and an issue, would like to make sure the users are very comfortable with the terminology and, more specifically, when using one or another. As you pointed, systems usually use the same nomenclature for identifying something outstanding. I believe that's mostly because users don't care ...


4

You may be confusing due date with a task being on the Critical Path. A path on the Critical Path must get done in order for the project to be completed. It is a firm constraint on the schedule and network of tasks. You can have many tasks that are due before a task that's on the Critical Path, but those on the Critical Path are more "important" ...


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

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

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

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

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

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. ...


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

The Key is Prioritization This is a bit of an X/Y problem, in that the issue isn't really whether you can track tasks in a bug tracker (you certainly can), but what value tracking really provides to a given project. The underlying process issue you're facing is one of prioritization. Any tool that lets you prioritize tasks by importance or due date, and ...


3

On a rather large integration project someone came up with a similar idea for tracking actions / dependencies. The idea was that these could be raised as Dependency Defects, which were essentially the same as normal defects but with a root cause of Dependency defined. Any actions blocking the completion of a test script could then be failed against that ...


3

It certainly is possible, and HP's ALM suite is more suited for that than just HP QC as far as I know. Usually to use it for task tracking, especially for developers, more integration with the development tools might be useful (e.g. http://tasktop.com/connectors/hp-alm-quality-center.php, but disclaimer, I work for Tasktop, so totally biased here). There ...


3

The idea is that most third-party queries/requests would be entered as an Issue, and then migrated into a Task and subsequently scheduled and assigned by the Project Manager What you're referring to here is a state change not a separate item. You need a way to capture the initial state of the item as an issue, and then a way to change that state to indicate ...


3

I think we're trying to solve the same problem, that being the challenge of prioritizing different types of work by categorizing at the entry phase or at least very soon after entry. I've worked with systems that have had a single issue type ("bug") to a current Jira implementation with three ("deliverable", "task" and "bug"). The one-type system resulted ...


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

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

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 ...


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