10

TL;DR Scrum is not intrinsically about doing more work faster, although high-performing teams often do. Like most agile frameworks, Scrum is about doing just enough of the right work. Measuring the team against a target velocity is a Scrum anti-pattern, as is measuring productivity from the number of backlog items or story points completed. Instead, you ...


5

I understand where you are coming from. However, I am unable to understand what you are trying to achieve from this kind of measurement. This practice of capturing productivity per programmer / developer based on defects and KLOC has reached its dead end. The practice of measuring was only during the Mainframe days (extended until Procedural programming ...


5

I would argue that there is no clear way of defining "efficiency" in any meaningful way. Assuming that efficiency is somewhere along the line of "value/time", you have two insurmountable problems: Value does not depend on the team exclusively: a very good team working on a very bad product will produce less value than the same team working on a very good ...


3

But you are measuring the effective work per sprint just fine. If the team delivers development work but not QA for a few stories, along with some analysis, but nothing else, then the effective work for your team for that sprint is zero. Because nothing of value has been delivered to the customer, and that's the value of a sprint. Not the "story points", ...


3

Communication is one of the most--if not, the most--important contributor to any project's success. If you don't have that capability, you need to get it. Buy it, hire it, do something or give the project up. And remember, communication is way more than speaking the language. That is the easy part. You have culture, norms, mores, folkways, taboos, and ...


3

Ideally you have someone from the culture that is foreign to you that you trust, who understands what you are trying to do, and is willing to support you. He/she/they can then interface with the operators while you interface with management, guide you through cultural norms, etc. Presumably he/she/they is/are less experienced than you, otherwise there would ...


3

Over the past 5 years, I have worked with Chinese, Korean, and Japanese speakers in a variety of projects. In my experience: Written correspondence is more successful than spoken communications. Writing in short sentences with simple grammar is more successful than the way typical American/British English have been taught to write Using references to ...


2

Scrum is all about adding business value and evolving an efficient delivery approach, so these are the things I would measure: Stakeholder satisfaction Product Owner satisfaction Progress against the organisations agile goals (e.g. reducing time-to-market) Effectiveness of the Scrum team's retrospectives and adaptions


2

Scrum of Scrums: How to make Scrum of Scrums meetings more productive? Agile EVM: I would also highly recommend to use Agile EVM if you have a budget too. Theory: http://www.methodsandtools.com/archive/archive.php?id=61 Practices: http://tempo.io/products/tempo-folio/ Scaled Agile: http://www.scaledagileframework.com/


2

Lean on the basics of project management. You have a list of tasks that need to get done and they vary in complexity and effort. Some of them will take a while, some will be short and fast and easy to do. Break down those tasks as far as you can to capture all of the things that are required for the overall task to be done. To measure your progress and ...


2

This is essentially impossible to answer. Consider that... the second dev - through more careful work or personal testing and fixing - ends up with less defects. But without knowing how much effort it is to fix all the remaining defects it's hard to compare the two measurements. you might not care about the defects at all. Your situation might call for ...


2

There is your question, and there is a question under that which deserves to be addressed. First, your question: Productivity is actually easy to measure. How many useful discrete units are produced. If you're measuring lines of code, then how many lines of code have a bug in it? The person with the higher number of bug-free lines is more productive. This ...


2

This is a “human’s” problem, hence you can only track progress by asking people questions about how they think the issue is improving (as Anton already suggested). I believe that you should have many integration sessions in order to allow the team to work together better. If you haven’t done that, this is a good time to start from scratch :) Also, can I ...


1

How does your sponsor want value measured? Your question indicates that the driver for your project was to measure (and presumably reduce) call duration. That would seem to be the likely first metric. Aside: Based on years of cynical experience, I'd suggest that you also measure rework - the number of calls that need to be re-opened or reworked. My current ...


1

First and foremost: avoid breaking down tasks by teams. Based on my previous experiences, it was always painful to put the pieces together retrospectively. So no, avoid the urge to create different tasks. Based on your example above, you have two different teams (development and testing) working over the same deliverable. Assumptions: You are using jira ...


1

The fact that only a small number of stories get completed during a sprint shows a dysfunction of your process and/or team, but it is highly questionable if splitting the stories in "dev stories" and "QA stories" is really going to resolve the dysfunction. The aim of a sprint is scrum is to deliver a potentially releasable product increment. A potentially ...


1

We see at the end of the sprints that not all the points are being completed. Yeah, this should not happen. Do everything you can to make this scenario very unlikely. For example, pull into the Sprint what would seem to be a ridiculously unambitious number of Product Backlog items (PBIs), with the aim of giving the team the experience of completing a Sprint ...


1

Some of the teams I worked with, had this issue. I have had a good degree of success by tackling this problem from multiple angles. Here is some of the Metrics/techniques you can use, how to get them: Periodic (once every sprint) retrospective. Facilitated well, to bring out real problems Implement (or make best efforts) on list of actions from ...


1

In our company we just periodically send survey to people asking how they feel. Main point here is to clarify for them, that nobody will punish them for setting low marks. Maybe make it anonymous. This is obviously very unreliable method, but only metric we found good enough. Better method is to talk with people 1-on-1 about how they feel in the team, in ...


1

It depends on your overall value proposition. Albeit simplified, consider two different types of home builders: one that produces a bulk of homes in a new development, largely the same, a ton of pre-built pieces, where speed to build, minimizing costs due to thin margins, and higher volume sales prevail; the other a custom builder, hired by a discriminating ...


1

Lean on some Lean Manufacturing metrics. (see what I did there?) Lead Time - Amount of time between customer request and delivery. Cycle Time - Amount of time between beginning implementation and delivery. Throughput - Number of requests you can deliver in a given period of time. Customer Rejects - How many times the customer requests changes post ...


1

As you mentioned you are familiar with Scrum and Agile Methodologies. Let's treat the current workflow that you follow for building the websites as a Story of a Sprint. While you are in discussion with the Customer regarding a new task, see if the task could be broken into Smaller units of work. In case possible create a Trello board and use it as a ...


1

Maximize business value delivered For a given team size (investment) you want the highest returns by way of delivered business value. Ideally, you should ask the Product Owner to assess this. However, this assessment by the PO will be subjective. So, you need an objective measure. In your comment, you said you wanted to compare performance for the same ...


1

Use the technology. Use technology translators like Google etc.. What ever you want to communicate to some one, type in English and translate the same. Check even you can get other way too. Get clearly clarity what you need to do and ask feedback in all the phases. Use more diagrams if possible so that it is easy to communicate and understand too.


1

Ignoring the elephant in the room Or: Major issues that do not get addressed (or better: they are addressed but get ignored), while the project keeps on going, eventually trying to deliver without resolving the issue.


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