Please be careful when using these kind of measurements as KPIs.
If you do this, I predict the following:
arguments about whether bugs are caused by development or by poor quality analysis
arguments about which developers caused which bugs
defensive programming, which will increase the maintenance costs
developers slowing down (no code means no bugs!)
I think you're also missing a few KPIs...
Negative points every time a Product Owner changes a requirement. They should have know what they wanted before development started.
Negative points every time a tester puts in duplicate points. Perhaps they get positive points ever time they find a bug?
Negative points to HR every time a "good" developer leaves ...
This is a bad idea on so many levels.
Lets list the ways:
Builds blame culture: everyone will be trying to blame everyone else for bugs that are found because it will affect their review
Encourages people not to take responsibility. If you do accept responsibility (it's my bug) then you get penalised
Hurts inter-team relations. Developers and testers ...
According to Mike Cohn
It’s quite common for a team to have a bit of unfinished work at the end of an agile sprint or iteration. Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case.
Accordingly to Scrum.org:
The Scrum Goal is the creation of productive and creative ...
Start with a high-5 all around! :)
Meet with your customer. Let them know you think you've completed the feature and give them a demo. Ask them if it meets their acceptance criteria. My bet is the customer will have some tweaks or changes now that they have seen it. By circling back to them right away, you've got a chance these changes can be made without ...
Performance reviews based on bugs is a pretty bad idea imho.
Even in best case scenarios where testers are assumed to be doing perfect work, it's very hard to implement some sort of bug tracker that doesn't produce side effects.
What you might consider is using some sort of metric for re-work hours. That tends to work better because:
You aren't telling ...
If you reduce a team from 7 to 4, especially if the reason is something outside the team, the best course of action is probably to treat this as a completely new team. People will need to change into new roles, find a new way of working together, cover fresh weaknesses caused by those leaving, find out who is in charge of what, and all the other problems ...
In situations like this two important rules are in conflict:
don't lie to the client
don't look bad in the eye of the client
Based on my experience, clients appreciate the outcome of the first rule, so if you are honest and tell them about the background of the issues, they'll most probably understand them (of course, there are client, who will try to use ...
I'm a bit unclear how you are managing the management/support requests. Actually, I'm unclear whether you are managing them at all. You need to manage these requests, to protect your developers.
Software developers can only be productive if they have extensive time "in the zone". Interruptions are the number-one thing that can kill developer productivity ...
Value Judgements vs. Flow Analysis
Considering a self-organized team where no individual work is ever reported, how do you spot the lazy team member?
This is the wrong way to ask the question, but it's understandable since people are social animals. The question is being asked through a social filter that imputes motives rather than analyzing the process ...
They should absolutely be doing QA. In fact, in the ideal agile team there are no specific roles.
Agile development is quite the opposite of the "throw it over the wall" mentality of development vs. QA.
Clearly the problem is: if a feature is not Done, should people get off the story and do something else? And if QA is not irrelevant (in other words, it ...
With no prior experience this is likely to be a tough ride. Listen, listen, listen to your team and others. There is a lot to learn for you. No two teams or companies are the same. Even with prior experience there is not cookie cutter approach to being a development manager or a project manager.
What I typically do when I start working with a new team is ...
A Sprint enshrines your empirical process by providing a maximum delivery cadence
It increases communication and alignment
It adds some predictability to the unpredictable nature of software by evening the batch sizes.
A Sprint is a container for planning!
While the Scrum Guide says that you must deliver working software at least every 30 days there ...
I'm not saying that I 100% understand what you need, but maybe your are looking for something similar to Personal Kanban. It
provides/visualizes you and your manager your actual status
can help you see your activities as a whole
helps you find your limitations (WIP), in other words how much tasks you can do in parallel
provides your manager the possibility ...
First, every appraisal, no matter who does it, is arbitrary to some point. If someone isn't fine with that they should find a place where there's no appraisals at all.
Second, for someone who is looking for feedback, more feedback should be always better than less feedback. I mean, even when I don't fully agree with someone's opinion it can still be very ...
I won't say that it is all about communication, but I think a large portion of the problem you see can be contributed to communications that could be improved.
I work in the same field, and I've seen this behavior from many clients in different industries. What took me a long time to understand was that the way I initially present estimates can have a huge ...
Programming generally involves taking many vague or abstract concepts and then tying them together to build something great. Judging developers based on the number of bugs in the code perhaps one of the worst ways an organization can shoot itself in the foot.
In a world where everything is so pro-Agile, there is no blueprint to follow. We're not ...
I support Zsolt approach, adding one suggestion when planning the way to deliver this information to the users:
Before the fix:
What caused (a misconfiguration on the application, a typo?)
Why it was caused (a last minute requirement change?)
why it wasn't noticed (lack of proper testing?)
After the fix:
Is there any potential similar problem somewhere ...
I would hope that by now you would have frozen scope as you have cited new requirements entering at the testing stage as a problem. That has to stop otherwise you are in an endless cycle.
Once you have stopped the scope creep there are a number of areas you need to look at. But the one that leaps out at me is System Testing. If the users are finding issues ...
Directly and honestly.
By the way, I think, this is a sales and negotiation question:
As far as I understood, you would like to support your customer and maybe earn some money. You would like to do both by predicting the future and you are (for whatever reason, time in your situation) not able to prove your prediction.
What is the worst case outcome?
The software project, already completed (and even then your historical data might be off by more than 10% depending on how you tracked it). Note: this is not a joke.
I am planning to give 40 points (my scoring system) to a developer, if he creates bug free code.
How about asking the programmers how much (money) they will fork out if somebody could show them how to create bug free code? Professional coding is no easy task and there are much better ways of judging good programmers.
Here is some reasons one ends up with ...
Reading between the lines a bit, it would seem that you have a few related issues.
Your "team" is too large to be truly agile. You may want to consider splitting up into cross-functional tiger teams with a focus rather than a multi-project, matrixed organization.
The purpose of your stand-up hasn't really been defined. Truly agile stand-ups ...
Use swimlanes on your board (or different coloured cards) to
indicate the type of work.
One team I worked with divided their board horizontally into two parts - the top for new product development work, the bottom for support/maintenance. Each steam had a separately prioritised backlog that the teams would pull work from when ready. This meant we always ...
checking SVN in a daily basis to review codes and to assess how much codes have been committed by each developer is a good way. is it fair and used in industry?
The proposed metric is utterly unfair, regrettably is used in some organisations and is in my personal opinion a recipe for disaster.
HasaniK and Jakub have already identified some very valid ...
The art of giving a SWAG estimate
I have worked with many developers and development managers who are very reluctant to give an estimate with such limited information and limited time. They have been bitten too many times in the past. The main reason is even if the people asking for such an estimation understand the risks and give an assurance that it will ...
Is it the responsibility of the Scrum master to intervene and interrupt a team member when he/she starts telling about points beyond those 3 that I mentioned?
Technically speaking, no. The purpose of the Daily Scrum is to facilitate coordination between the the Team. It's not for the Team to call off those three points by rote. Many Teams don't use the '...
Will the software ever change after its first release?
Waterfall is for building bridges and houses -- physical, rigid things that you don't expect to change much over time.
Agile and Iterative approaches fit naturally with software development and its fluidity.
You should expect and embrace change.
I understand not everyone agrees with this, but using a ...
option 1: it might work if you make these standups extremely quick and efficient (15 min is the maximum, standup could be much shorter)
option 2: sounds like a disaster to me; having so many people and projects, it would be impossible to process it all in a meaningful way and still keep it under 15 minutes; you might end up with long boring "standups" (I've ...