views:

231

answers:

7

hi,

we have started to work in scrum methodology, and i always get me development be disconnected from the time frames we need to align.

how you make your team members to be aware of the time they have committed to perform each coding task?

how do you make them aware of the general time frame i.e. releases etc

are there any software solutions for that? some sort of counters on the desktop ... etc.

A: 

We use http://www.atlassian.com/software/jira/ and together with http://www.atlassian.com/software/fisheye/ and http://subversion.tigris.org/ it does all of what you asked for.

The scrum related JIRA extension is http://www.atlassian.com/software/greenhopper/

Whether the team is distributed or in the same office, does not matter. These kind of tools are necessary in both situations.

cherouvim
How can you actually make JIRA count the time you spent on a task? We use it too, and we have to manually log work for tasks.
Péter Török
@Péter Török: we use "start progress" and "stop progress", but yes, work logging happens manually afterwards in the issue. Of course there is Mylyn (http://www.eclipse.org/mylyn/) which should allow you to do that from within the IDE.
cherouvim
+1  A: 

I don't know of any tool-based solution, but with some practice everyone can get into the habit of (mentally / on paper) recording when (s)he started a task and logging the time spent when finished (or interrupted).

Péter Török
A: 

You can use tools like fogbugz that have a way of inputing time spent on each task. Then it's just a matter of getting the team to input their time correctly or use timers.

To make them aware of timing, you could use a shared google calendar for instance.

If you really want to work with a scrum methodology, I recommend using Pivotal Tracker, it's free and awesome. You can't really track time, but the other features makes up for it and there are good ways of communicating deadlines/releases and so on.

marcgg
+1  A: 

Why do you need to track the time that has been spent on tasks? The team could very easily interpret this as a lack of trust in their ability to deliver. This seems to be a command and control technique that is possibly contrary to agile thinking?

I am a great believer in tracking the remaining effort only. So long as the remaining effort on each task is realistic and frequently updated, you can create a burndown of the remaining effort. This is the team's most valuable indicator of progress towards the target.

One way to start the process of tracking tasks is to use a whiteboard to create a taskboard. There are lots of articles on the net about how to do this. There is something tactile and engaging about using a physical taskboard over software. Obviously there are limitations, especially if the team is distributed and not collocated.

Clive Skipper
You have to get statistics comparing initially estimated time with actual time for past developments. This allows iteratively improving estimations.
Joeri Sebrechts
+3  A: 

Scrum has several practices that mark the rhythm of the Team:

  • the daily scrum
  • the sprint planning meeting

Then the burndown chart shows the amount of work remaining for the sprint decreasing.

Big visible charts or information radiator in the team room display important information. Here is an example from Henrik Kniberg "Scrum and XP from the trenches" excellent book:

alt text

On this panel, Team members can get a feel of the Team progress for the current Sprint, the backlog items complete (Done column), those in progress (checked ot) and not started (not checked out). The tasks (on the yellow stick notes) have their duration estimate hand-written on them, possibly updated.

philippe
+1  A: 

You can keep your team aware of releases with regular communication - for example at end of daily standup you could give a 30 second summary on whats going to happen when.

Keep a whiteboard nearby with countdowns on for days to release, bugs in system etc this could be the same whiteboard displaying your user story progress.

Also using Scrum methodology your development iterations should all be the same length so your developers should become used to a regular release cycle.

For a particular task, if your working with hours then you should get your task updated daily with time remaining. It should be emphasised this is a daily task and shown why its important ie - show the burndown graph at end of daily standup.

On software TFS has time remaining/estimated for tasks.

I wouldnt recommend being so exact as having timers on desktops, I dont see how they will work without manual intervention. Which would be open to inaccuracies. I tend to jot down a ticket numer or a few words describing what I'm doing then update each day.

Paul Rowland
A: 

JIRA combines issue tracking, agile project management, customisable workflow, and a pluggable integration framework to increase the velocity of your software development team.

JIRA full feature list

masoud ramezani
LOL, is this some kind of advertisement?
Pascal Thivent
We use jira in our team. this software is very powerful.
masoud ramezani
@massoud While this is definitely true, the sentence *"With JIRA at the centre of your development team, delivering quality software on-time has never been easier."* really sounded like a glossy brochure :)
Pascal Thivent

related questions