The project velocity is one of the terms that you come across while
discussing about the iteration planning and release planning! The project
velocity has a got a very important and not to be ignored part to play in these two mentioned
planning processes but still most of us are not aware of its importance.
This
article is centred on the project velocity and has been discussed in detail.
Like the normal physics velocity, the project velocity gives the speed of the
development of a software project.
In other words, the project velocity gives
the amount of work being and efforts being spent on the software project.
About Project Velocity
- The
project is simply the summation of all the estimates of the user stories that
were involved in the iteration.
- For the release
planning, you add up the estimates of the user stories and for the iteration
planning the estimates of the programming tasks are added up.
- But anyway, both
the factors can employed for determining the project velocity in the case of
the iteration planning.
- In the iteration planning meeting, the number of the
user stories chosen by the customer is same as it was in the previous
iteration.
- There is a rule that the project velocity of the consecutive
iterations must not exceed their preceding iterations.
- These programming tasks
are nothing but a broken down or divided version of the user stories.
- The
development team is supposed to take up or sign up for only the same number of
tasks that were present in the previous iteration.
- Such an arrangement proves
to be a great help to the developers when they stuck in a sticky situation and
need to recover and clean up from it and thus getting the average for the
estimates.
- The project velocity is suppose to rise when the developers are
allowed to question the customers for other user stories when they have already
finished their work and tasks like cleaning up are also accomplished.
Please do
not think that you will get the project velocity consistent throughout the
development cycle! It is expected to follow through some ups and downs.
- But if
a dramatic change is observed in the project velocity, then it is an issue of
concern.
- But there is no need to worry since all this can be kept in check by
re- estimation and re- negotiation of the release plan.
- It is not just in this
case that the project velocity may change!
- Even when the system is put under
production for the maintenance tasks, again the project velocity is subjected
to changes.
- Division of the project velocity by the length of the iteration or
the number of people involved.
- Furthermore, the number of the people involved in
the iteration is not an appropriate way for making comparisons between the
productivity of two products.
- This is so because each and every team has got its
own different criteria for estimating the user stories and so we get some high
estimation and some low estimation.
- Important is to keep a track of the amount of work being done on the project
so that a steady project velocity for the development can be maintained that
can also be easily predicted.
The problem comes while making the first
estimation!
- At least for the following iterations you will have a clue that
what project velocity is required.
- If this measure is used properly you may be
able to detect a major fault in your project much before the time at which you
would have known with the help of the traditional development methods.
No comments:
Post a Comment