On my current project I mark down 80% of my time as spent on fogbugz tasks, and 20% on other things.
What is the correct way for me to update the "working on" status? Should I switch it to "nothing" for the 20% of other activity, or is that taken account of automatically?
If I do switch to "working on nothing" when doing other activities, how can I keep track of how accurate my 20%/80% estimate was in the long run?
It takes this into account automatically. You don't need to stop and start the clock. If you work 8 hours a day, it will assume 1.6 hrs were spent doing other things (like lunch).
The best I can think of, if nobody else answers this, is to create a schedule item for my "other tasks" and assign time to this item, so I can keep track of how realistic my 80/20 estimate is.
If I don't want this to affect my estimation history (as it's not a programming issue) I think it's possible to discard the estimate from my estimation history.
Related
My team is using TFS2017 and we have some 100+ past iterations (sprints) in our backlog/board. (I'm talking about Past, Current & Future iterations). We're only interested in 5-6 most recent Past iterations and scrolling to the end of the list is generally annoying.
Is there any way to change the sort order of the past iterations to descending?
If this isn't possible, is it possible to create a new group/item/list/whatever besides Past, Current and Future, called Old iterations (or something like that)?
Thanx in advance.
To reduce the number of iterations on the "Past" section you can configure in the team settings to see only the iterations of the current year.
Press on the Gear icon when you on your team page --> Work --> Press on "Change" near the "Backlog iteration".
After that, you will see only the iteration from the current year and the scrolling not will be so annoying...
I have been using TFS to track my backlog items and I am now trying to write a query to see how long I took on particular tasks in the last 7 days. So Far I have this query:
Work Item Type = Task
AND State = Done
AND Closed Date = #Today - 7
AND Area Path = #Project
AND Assigned To = #Me
and have added the column "Closed Date" which shows the time work stopped on this item. But I cannot get any information as to when work started on the Task
Feels like the data should be there as on particular tasks it has the following kind of information:
Is this possible? I don't mind extracting the data to Excel to analyse.
The reason I ask is because I would then like to go on to compare the amount of hours assigned to a particular task and compare it to amount of hours actually taken to help my predictions of time taken in future.
It's a pretty simple query actually.
Here's what I'm using.
(Work Item Type = User Story
OR Work Item Type = Bug
)
AND State <> New
AND State <> Removed
Simply include the Activated Date, the Resolved Date, and the Closed Date in the displayed columns. The time between Activated and Closed is your total cycle time.
My team uses Resolved as a "pending deployment" status, so comparing Resolved to Closed allows us to determine how long it takes to get an item from "done" to "in prod".
TFS is not intended to be a time tracking tool. You could query the work item history with the TFS API and check the timestamps on when the state transitions occurred if you really wanted to.
Agile projects don't focus on how long individual tasks take -- they focus on how much value the development team is providing over the course of a set period of time. One thing might be estimated low, one task might be estimated high, but it ultimately doesn't matter as long as the team delivers what they committed to deliver.
It's a good practice to track Cycle Time for a team to discover areas for improvements (for User Story level, yes)
It's not good that user must go Excel to calculate Cycle Time. I can't use diagram Azure Devops tools with this calculations and its not automated.
Cycle Time widget don't shows results for several teams and it's not flexible tool, so it's not enough
I execute queries that go through the whole, quite big graph. At the moment some of them take 10m and others go up to 3h and even more. However, it is just a start. I already have to break some of them after a few hours because I do not know if they will end in ten minutes or 10 years. It would be very helpful to see some kind of progress during the execution.
At the moment such a feature does not (yet) exist. There is a plan to provide a way to kill a running query conveniently in one the upcoming releases.
In the meantime you can go with a feature that is not part of the public API called guards. Mark did a nice writeup at http://www.markhneedham.com/blog/2013/10/17/neo4j-setting-query-timeout/
How would you update attributes in your database based on the time of day or what day it is. I have three attributes energy, hunger, and happiness that I want to decrease by ten every hour but I don't quite know how to go about doing this. I know there are timestamps in the database but I don't really know how to use them. Also I want to change the players skills every day based on their job. So if you have this job, add 2 to intelligence every day. But I don't know how to add that 2 every day. I would love it if anyone could give me help on this problem. I would greatly appreciate it.
A couple of options:
cronjob: You could setup your cronjob to access the database directly through a SQL script (probably the simplest solution out of all in terms of setup) or go through your rails application first (e.g. in case you need to run additional business logic before updating the database - you mentioned something about updating the database based on the user job). See this post for the latter approach.
Background task: Take a look at Starling/Workling or Backgroundrb. You can use either of these to run a background task that could update your database at regular intervals.
There are two common but fundamentally different ways of achieving this:
During each request, simulate the amount of time which has passed since the last request. If a user makes two requests three hours apart, simulate three hours of time passing by subtracting 30 happiness (10/hour times 3 hours) all at once. This is less resource intensive, but requires a little more thinking on your part. It's not difficult for something as simple as "lower a value by 10 every hour", but more complex interactions are more difficult to model.
Run a cron job which invokes an action in your program every hour, on the hour, to deduct 10 happiness from each account. This is easier conceptually, but involves a lot of overhead if you have many users, especially when some of them are idle for long periods.
I made a mistake when entering my sprint plan in Jira/Greenhopper: it turns out we have a little bit more capacity than planned.
This happened the second day of the sprint, but if I add the extra issues after the beginning of the sprint, the red 'guideline' starts from our original estimate.
Is there a way to avoid this?
I've encountered the same desire to 'adjust' the guideline in the sprint report a few minutes after starting a sprint.
I've solved it in the following manner:
Go to the 'Plan' tab on your Agile board
Set the start time of the sprint after the the timestamp of your adjustment
Check the sprint report (it should be fixed)
As I understand the question the problem that you are facing is that the red guide line is drawn from the amount of work entered at the start of the sprint down to the end date for the sprint.
When you add more work to the sprint after the first day the guideline doesn't move. This can't be changed. See the thread here for discussion on that topic.
I think the logic here is that you should have all of your work defined and estimated at the start of the sprint and if the estimate increases after the first day then that should be because the tasks are more complex than first thought, not because you added more work.
I agree that it would be good if there was a new 'line of best fit' between your current remaining work and the end date to show the new level of velocity you would need to reach, but that is not supported.
I've added stories before to an iteration, and the burndown just ticks up with the additional, to show what else has to burn down. Greenhopper will represent the uptick an adjustment to the estimate, since it was added mid-iteration, but the remaining work is increased and then continues to burn down appropriately.
Abnormally terminate the sprint and restart it could be an option here. Since you already have the bulk of the items selected the sprint planning meeting for this could be in a very small time-box. Since you abnormally terminate you definitely can skip the sprint demo, you may want to have a short retrospective if you want to discuss how the problem/error happened, but I doubt it. You could be up and running with a new sprint in a few hours.
A late added task can be forced to be considered at the begin of the sprint using a workaround: log a minimum amount (1minute, e.g.) of work at the sprint first day.