We’re rewarding the question askers & reputations are being recalculated! Read more.
25

My team uses Lego to track work done and what we're spending our time on. This was our last iteration (two weeks): The section at the front shows task completion. White bricks are added when a task is developer done and committed, orange bricks are added when they're QA complete. The section at the back shows what people spent their time on by day. We ...


19

In my opinion, gamification of time-tracking shows that you've either failed to do anything worthwhile with time-tracking data, or you've failed to communicate the worthwhile things that you have done. A random website gives these as the top reasons to track time: Data for future project costing/estimation. The ability to value work in process (especially ...


19

Coordination/Collaboration, Not Formal Task-Tracking While the Scrum Guide used to refer to the stand-up as a commitment meeting, it currently says: The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The purpose of the daily Scrum is not to hold people accountable ...


12

Most common metrics used along with Kanban are: Cycle time / production lead time There is some confusion over naming so let me explain in a bit more detail. Production lead time or cycle time is time that elapses from the moment a team starts actively working on a task till the moment they are done (or done-done). This metric basically say about how ...


8

Based on my own experience I would recommend Jira or Mantis. Jira is a paying solution but is by far the best I have used. It has agile plugins like greenhopper, ideal for visualising the workflow on cards. A free solution that might work: Mantis is a open source bug tracking solution that works very well.


8

Actually this is one of the reasons why we need managers in agile teams. The team's responsibility is to back up weaker members and deliver. It doesn't mean however that poor performers should have an easy life in agile teams. One thing is to get the job done, another is to tell who did heck lot of work and who was just standing on the side watching how work ...


8

Tracking the daily commitments each team member sounds like micro-management at its best. The exception would be for a very short project, or for a tiger-team trying to solve an emergency. When you track daily commitments, either the larger chunks are being ignored (woe to the project) or else they are being unnecessarily broken down into meaningless ...


8

TL;DR You have an X/Y problem created by skipping over analysis of the process problem in favor of a tools-based approach. JIRA and GitHub Issues are tools, not processes, so until you fully define your process flow you will remain at disadvantage. You need to define what you are tracking, why you are tracking it, and how you will use the tracking data to ...


7

That is called a variance. It is not a missing task. It is work in scope but not planned. This means you cannot claim EV on that package until the extra effort is finished. You will accrue an unfavorable SV and CV. The four legs example is iffy. If you had explicit requirements about the three legs, then you have a change. Add it and strike a new ...


7

"I'm wondering if a gamification approach to time tracking would help..." I believe that gamification has the potential to solve the problem with engagement, but it also generates some serious risks of unintended consequences. if very engaging, employees may spend too much time on time tracking / playing the game; this may make work more fun but may ...


7

Management Owns Cost-Overruns A Developer estimates between 70 to 100 hours for a task. Due to the urgency of the task and the developer's unavailability, a far less experienced developer is assigned to the project. The new developer takes 200 hours to complete the task. This is the agency's responsibility 100% of the time. Whether the estimate was wrong,...


7

Stuff like that should be in the working agreement of the team. There is no right answer on how to handle the situation but there are pros/cons of creating the story/defect and/or underlying task. Pros: Creates visibility for the rest of the team Leaves an artifact that the work was done Cons: Administrative overhead associated with creating/managing the ...


7

TL;DR Even when the change is apparently minor, it can have ramifications. The "one-minute fix" to some CSS class might impact the user interface (UI) on some other page the developer isn't thinking about, or might break important regression tests. This is the very definition of cowboy coding. More importantly, bypassing the agreed-upon workflow is a ...


7

+1000 on Daniel's post: Do not use task hours at all. Hour estimating is something you'll find a lot of the leading agile experts recommend. And then look that the time stamps. I'm not aware of any leading agile voice that still supports hour tracking of tasks. It's been deemed counter-productive to relativistic estimating of story points. The goal of ...


6

As simple as it sounds, the daily scrum and a whiteboard are the two best tools for managing this kind of uncertanty. At the start of the week plan out what you think you need to get done, given that it may change daily and introduce the plan to your team at your daily scrum meeting on Day one (Monday or whatever day your planning week starts on) and put ...


6

Schedule statusing and analysis should occur on an established frequency based on the length of your project, primarily. This type of control work is expensive so you want to do it as infrequently as possible. Not only this, but the more you dig in, the more you will compelled to chase variances, which is often nothing more than stochastic ebbs and flow, ...


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

Agile provides 3 opportunities to catch this error prior to production The dependency should have been captured in the acceptance criteria: When story B is written, it should have been linked back to story A. And an acceptance criteria should have been written to capture that. Unit test should break: While not all Agile teams may be writing unit tests, ...


6

From the process point of view there is nothing wrong with it, because this is the closest thing you have for tracking. However, it may harm the team members on the personal level, and can easily lead to micro management. They may feel an unnecessary pressure on themselves in order to keep the commitments, even if it is not possible to finish the task in a ...


6

The reason Scrum teams often use story points for estimating is that it provides an effective way to calculate the capacity of a team. They also allow for lightweight forecasting when doing release planning. The reasons they use time-based estimates on tasks is different. It is so that they can: Spend time breaking work down, which often helps when it ...


5

Trello is a new product anounced today, but it looks like it matches your requirements: http://blog.trello.com/launch/


5

Effective agile development requires an environment in which an individual is safe to put the "we" before the "me". As such, the idea of "individual accountability" is capable of fundamentally breaking agile teams, preventing them from making the teaming transition from "Forming, norming, and storming" into "performing." As such, I typically encourage teams ...


5

The first thing to remember is that points != time; points are a relative estimation of complexity. While you could get a sense of hours-spent-per-point using the length of the sprint and velocity, that's not the purpose. Tthe way I typically handle sprint planning for an environment in which customers will inevitably be reporting bugs against software in ...


5

TL; DR You do not necessarily have the same "project" across multiple platforms. You must identify whether you are producing different (but similar) products that form multiple projects, or a single product with multiple front-ends that can be treated as a cohesive project within a single team. Scrum projects are generally based around a "one team, one ...


5

Just do story points! If you already gained information about your velocity you don't need to estimate hours additionally. Usually we estimate only the complexity of the story and in the planning the team gets the chance to reestimate the story after planning all the tasks. The team then commits only those stories they manage to do in the sprint. -- Edit ...


5

TL; DR- Tie individual KPIs/OKRs to developmental goals unrelated to the product/project they are working on. My advice is based on a successful implementation one of my own agile mentors did and I hope to do someday with one of my clients. They overhauled the entire HR review process and put in place a 50/50 model. The first 50% of your review is based ...


5

As you are referring to sprints and user stories, I will assume you are using the Scrum framework. Within Scrum, there is no such thing as a partially complete user story. A user story can either be done, in which case all acceptance criteria and the definition-of-done have been fulfilled, or the user story is not done. When, at the end of a sprint, some ...


4

Individual velocity is a dangerous measure. I worked on a team once in which the dev manager wanted to measure individual velocity. She intended to use this for raises, meaning she would both compensate those with the highest velocity AND look for consistency in each person's delivery rate. This was a disaster. Devs stopped pairing, they were less ...


4

I have had success with the time tracking app: TSheets. It was easy to learn and its functions allowed me to to track several employees time spent on a variety of tasks (i.e. marketing, development, sales, website, etc) from all different locations (different laptops and iphones). It would be worth checking out their free trial to see if it's as user ...


4

look into jira from atlassian. While the defaults are sensible for software development, you can customize tasktypes, workflows (per tasktype if you really want), input forms/layouts (per transition), attributes, whatever. The package might seem complicated at first, but it is very powerfull and customizeable. If you need some details, they have good ...


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