21

when pushed to do 60, they will deliver 60. This is a pretty meaningless measure in these circumstances. A team could drop quality to deliver more points or simply game the estimation of stories. Story points and velocity were designed to help teams estimate their capacity in a sprint. They are not intended to be measures of performance. If you want to ...


9

Velocity Isn't a Productivity Metric In other words, when they are left to decide how much is too much, they will say commit to 40 points, whereas when pushed to do 60, they will deliver 60. If you are managing to a velocity metric, then you're Doing Scrum Wrong™. Velocity is a capacity metric, and has no utility in measuring a team's productivity. Even ...


7

This is a pretty big question that might create a lot of advice, but I'm sure there are also nuances that we will not get here. There are also multiple questions and challenges embedded into your question so I'm going to answer generally. You are right that grouping by areas of expertise is considered a bad idea as now no one group of people actually has ...


7

TL,DR The throughput of an outsourcing team depends mainly on culture and expectations on them. Consider both aspects before acting. I believe there are a few aspects that are prerequisites to be understood before entering into the actual solution. Why Outsourcing? First of all, there's a reason why companies outsource to offshore locations. In most of ...


6

It sounds like you've got a few layers of challenges. First and foremost, it doesn't sound like you have a team so much as a group of people that have been put together on an org chart. If the different team members can't support each other, then you'll lose most of the benefits of a team and team-based estimation is useless. If that is the case, then your ...


5

TL;DR Communications planning is an essential part of the project initiation process, and some methodologies (e.g. PRINCE2) include it as a formal documentation process for that phase. The specifics of your plan, as well as the pros and cons of any given control, are very situational. Specifics can't be effectively addressed outside the context of your ...


5

It is a poor workman who blames his tools. The false premise underlying this question annoys me; I have rewritten this answer several times to try to take out the withering sarcasm and the ire, but I think that ultimately it is more honest and effective to admit that I am working hard to be respectful while I am annoyed. I have worked on teams that rely ...


4

Getting started with a distributed software development team Welcome to PMSE! You said your team will be doing web and mobile development. Even though your question is very broad, I am taking a shot at an answer. If you have follow-on questions, please feel free to post them here as new questions. Pick a development process - here is the super-short ...


4

I concur with some of the other points made, specifically: Not really a team and sounds more like multiple teams of one. Knowledge dissemination is also an issue. No real benchmark for the estimating. I would add the focus of the question seems to be on finding a tool to overcome...something?? which makes me curious. What interactions are you trying to ...


4

It seems to me like you have two issues: lack of knowledge dissemination, and lack of an estimation benchmark. Knowledge Dissemination Currently it looks like all of your developers have a bus factor of one. If any of your developers gets hit by a bus (or quits, or gets fired, or goes on a long vacation, etc.), then what happens to his/her project? S/he's ...


4

All the team members can agree on some set of guidelines to help. We are following these fun guidelines that are working very well for us: No person can talk for more than 1 minute at a time. Every person in the team must talk. Every person must nominate the name of another person in the team, at the end of his/her turn. The nominated person will then talk ...


3

You can choose to go one of two ways. Detailed, up front requirements. Very precise, not flexible and required a lot of up-front work. Goal based "Stories" that describe what the end user experience should be like. Remember the end user does not have to be the guy on the street. It's who will be using it day to day. Doesn't require a lot of up-front ...


3

If you ask if Kanban is going to help you deliver, it won't. Actually, none of the methods will. There is the project management triangle. If the time which says that you cannot have all the angles - scope, schedule, and cost - fixed. If your scope and schedule are fixed, the only thing is left for you is to hire more people that increases cost, increases ...


3

I've had 2 experiences in the same company with distributed teams: In the first experience, I was Scrum master and I had 2 members abroad (with 8hrs difference). We just couldn't control how much time they were exactly working on the project and they were constantly pulled onto other projects of the remote location. It didn't work smoothly. In the second ...


3

It's a matter of risk management. Clearly you can start the dependent work early, but doing so incurs risk on the project- How much risk is determined by the a number of factors but two key factors are: The approach you take to defining the interface up front in the absence of the right resources and clear requirements What is the impact of getting it wrong?...


3

I don't think there is much flaws in process which you mentioned. My suggestion is, as you said team should not have 30 members. Ideally in Scrum, the team should be 7 to 9 members. It includes dev team, testers, scrum master and product owner. I would suggest to divide your team to smaller units and have a Business Analyst who manages the team goals, Scrum ...


3

This is still a very complex question, and I think it is possible that an answer will nail a part of it and miss the whole. I'm still thinking about the problem, but in the interim, I found the following quote today The design specification must be governed differently than the requirements. If the requirements were appropriately governed, and if the ...


3

Your Question, Redefined My main concern is people dropping out and leaving half finished work behind but I'm sure there are other challenges I need to consider. There are many such challenges with any drop-in/drop-out resource matrix. Your question is broad, and not fully answerable in it's current form. However, I think it's answerable if you redefine ...


3

I'm currently managing 7 teams that contribute to a single project. While we're one large "team", each team does their own estimates. This sounds very close to what you have -- one large team, made up of several smaller teams. This is where your problem can be solved -- recognizing you have multiple teams. Each team should be responsible for their own ...


3

Recommendation: Split the team in into 2 teams Goal: Team doesn't have to take hit of staying late / coming early Prerequisite: Stories teams going to work should be independent as much as possible. Cons: Scrum Master has to repeat the ceremonies for both the teams. Risk: Team alignment on work progress / status Risk Mitigation: Scrum Master shares the Work ...


3

I have 13 years development experience. I worked as an outsource engineer for Weight Watchers from Jordan, and then later in my life I did manage outsource teams myself. I also managed onshore teams. Managing teams when they are offshore can be different, but motivation i don't think its much different specially for talented engineers. Whatever motivates ...


3

The first item in the Agile Manifesto is: Individuals and interactions over processes and tools Your question lists a bunch of tools and asks about more tools, some that are more flexible to use given your new situation with people working remotely. How about turning the problem on its head and think about improving the interactions between people? At ...


3

A few additional suggestions that we've tried with some success: To specify seating order, you can do things like: have everyone roll dice (slack has a D&D dice roller app, use /roll d100 to get a good dynamic range) have everyone say their favorite color then go in spectral order choose the first person by something lighthearted like oldest car, or ...


2

And how about not estimating at all? Just count the number of stories (each is 1) and thus discover the team's velocity. I heard promising stories based on this approach. Alternatively you could use Small (1) Medium (2) and Large (3) estimates.


2

Have you tried simply counting the stories/tasks/PBIs/Whatever per period of time? There have been multiple studies done that show SP estimation is only marginally more accurate. The increased accuracy is arguably not worth the extra time (and aggravation) it takes to do story point estimation. I've presented about leaning out your estimation process. (press ...


2

If you are the decision maker as to which team each new employee goes, then I would suggest to remove the team lead from the equation in this situation and here's why: In this situation, since each was hired generically and then are to be assigned, I would remove the team lead in choosing, so as to avoid the fight you are experiencing and because their ...


2

I'm not all that familiar with the details of ITIL. When I've run across it, what I have usually found is the process was stagnating the origanization. What I would advise is flip things around, instead of laying in a large process (with all the documentation, training, ramp up, etc), start where you are and develop something from there. This falls under ...


2

TL;DR Give them the problem to solve, tell them why it's valuable, and introduce them to the real person who has that problem Better requirements are only a small improvement; forming a cross-functional, self-organizing team removes a major barrier to the development team being awesome. Requirements My advice regarding requirements writing is to write them ...


2

Regardless of the type of project, it is difficult to go wrong by following the INVEST framework. You've tagged your question as Agile. Are you using user stories? Do those stories have tasks under them? Because those are where the implementation details should go, and it should be the developers who set those up. The idea behind a user story is not to ...


2

From my perspective it is a human resource issue but then with project operating from multiple location / countries across the globe it is one of the situation that you will find occurring quite often. Approach that I would follow given this situation is: Figure a common language which most of the people are comfortable if not fluent. Keep communication in ...


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