81

Is Planning Poker Bad for Software Development Teams? This is the wrong question to ask. Planning poker is a tool. Asking if planning poker is bad for software development teams is like asking if a screwdriver is bad for plumbers. If the tool fits the job then it's a good tool, if not, then it's not. The real question you should be asking yourself is: ...


28

TL; DR Your question embeds some false assumptions about the linear nature of testing within an agile process. A mature agile team with cross-functional skill sets treats development and testing as intertwined activities rather than as sequential ones. You should strive to integrate development and testing so that they are not fundamentally separate work ...


23

TL;DR What is industry standard of how many projects one PM should manage at the same time? There's no such thing; individual projects vary greatly in the level of effort required to manage the project properly. In addition, each project management framework varies in how much overhead is involved. Therefore, the correct question is "How many hours per ...


15

I can feel the frustration in your post. As someone who made the transition from a PMO to an Agile role I can understand both sides of the coin. Your question has multiple components which I will take in turn but all of them have effective communication at their core. Why are management more interested in logging hours? This could be a number of things but ...


15

Person-month is politically correct synonym for Man-month. It's mean amount of work performed by the average worker in one month. So, if: project requires 12 persons-months of development time all team members do only pure development activity (i.e. they are telepaths and they don't need to spend time for communication with each other). [note: this is not ...


14

TL;DR You have already decided, a priori, that team member C is the problem. This is based on information you have not provided in your post. As a result, this appears to be a false conclusion that papers over a process problem that you (as the project manager) are responsible for uncovering. The Problem Given a task X, developers A and B would each ...


11

Planning Poker isn't the only way to estimate and lots of teams get on well with other methods. More experienced teams may find they can reach a consensus estimate via a quick conversation instead. The idea of poker is that it encourages the whole team to contribute an estimate and that everyone's opinion is important. Averaging is reasonable if the ...


10

What is important is not really how long these events take, but if you get the desired results from them. For example, the Daily Scrum could take only five minutes because everyone is just giving a task board update and largely ignoring each other, which would of course be bad. On the other hand, it could take 5 minutes because everyone talks throughout ...


10

Multitasking kills productivity. Task-switching costs can be deadly. What I would suggest is to make Management aware of the costs and risks of having developers working on multiple projects simultaneously. Even if for some magical reason task-switching did cost 0 time, why would you want to finish Project A and B in ten days, when you could instead focus ...


9

Cone of Uncertainty Research in the software industry on the Cone of Uncertainty stated that in the beginning of the project life cycle (i.e. before gathering of requirements) estimates have in general an uncertainty of factor 4 on both the high side and the low side (Boehm 1981). This means that the actual effort or scope can be 4 times or 1/4 of the first ...


9

We estimate as a team and then take the average Good grief, don't take the average! That's not how planning poker is played. Here's how I teach my teams: start with a brief discussion of the work involved play round 1: everyone shows their card. then the highest vote and the lowest vote each explain their rationale. Perhaps further discussion ensues. ...


8

Why is management is more concerned of JIRA burndown chart than of following Scrum values in project development? 3 common reasons for this type of behavior are: Lack of trust Poor understanding of Agile methodologies; still thinking in waterfall terms Delivery Team is not meeting commitments Why do some members of the team not like to log hours in JIRA ...


8

They could be doing a number of things. What they should be doing depends on your organization's Scrum/XP maturity but here are some common items: QA work - yes devs can QA, whether thats writing new automated tests, upping existing test coverage or reducing test complexity, doing manual testing, or performance/load testing, devs can and should QA. The ...


7

To make it easier to log hours in Jira you can use the worklog assistant program. The worklog assistant grabs all filters from Jira, you get a list of the current sprint issues for example. It warns you when not logging time. Its possible to publish automatically or do it manually and correct some logging when needed. Create some place holder tickets for ...


7

Not to be pedantic, but the correct way to write the term would be person-month, or man-month. The distinction is that person/month implies units of people per month. This is inaccurate. A person-month is a unit of work that's calculated by multiplying the number of persons by the number of months they work. So a team with three developers working on a task ...


6

Saakyan, no human resource is ever 100% productive. Non productive time, including necessary work but not tied to a specific task as well as simple down time, always exist and should exist because of the inherent benefits of rest. The range of productive time you should be using could be as low 50% but likely never higher than 75%. Also, other things that ...


6

The purpose of the time boxing in Scrum is to act as an alarm for the Scrum Team. When the time boxes are regularly being exceeded then there is a problem that needs to be addressed. As a Scrum Master this is what I would do in this situation. With the Daily Scrum I would not interrupt the meeting at 15 minutes. Instead, I would look to interrupt ...


6

I believe, there are no formulas for calculating "scale factor". There are too many factors, that may affect this parameter. Such as: Can work be done in parallel? Complexity of whole project. Communication ability of team members. Organization of your working process (take a look at this question: Number of communication channels in Chief-Programmer model)....


6

Honestly, as a technical lead of many teams, I will say if anyone had a formula for determining velocity, I would deem it ignorant at best, and out-right harmful at worst. Velocity is descriptive, not prescriptive. It is our jobs as leaders to use the data that is flowing in to forecast the future, but by no means could anyone say for an absolute certainty ...


6

I've been very successful as a program manager and now agile coach, in Silicon Valley, for over fifteen years based on a completely non-technical background. I've faced this argument many times in the earlier stages of my program management career. My technical skills are at a basic advanced computer user and I've never coded. When faced with these ...


6

It sounds like the Cone of Uncertainty. The idea is that at the beginning of a project or effort, there is enough uncertainty that estimates are generally in the range of being 4x over or 1/4 of the time it will take to complete. As the project progresses, these uncertainties begin to be resolved or better understood and the range of estimation becomes ...


6

TL;DR If your employee truly is bored, and one or both of you think this is actually a problem that needs to be solved, ask her for solutions that suit the both of you. The path to professional self-actualization for both of you starts with communication, collaboration, and alignment. You need to address those dynamics before you can properly measure or ...


5

I will argue that writing code is probably one of the least important parts of the project. In my view it is a means to an end, at the end of the day you are translating the requirements of a customer into a particular syntax that can be executed by a machine to deliver benefits to that customer. "Requirements gathering, business and systems analysis" and "...


5

You need to understand why developer C takes 5 times longer. It's an awkward conversation, but you need to let C know that you feel he takes significantly longer than the other developers to get X done. Then simply ask him why. There are countless valid reasons that developer C might be performing under power, from needing to skill up in a tech but being ...


5

Before I get into the answers you should know that to me it sounds like the real root cause here is you don't have a good scrum master. Your scrum master should be able to handle most of these issues - and it sounds like they are not stepping up and coaching the team on how to improve their process. That said - here are my responses to each of your questions:...


5

TL; DR You and the customer have both fallen prey to the "100% utilization fallacy." This puts the project at risk. Build more slack into your project management process, not less. Analysis [T]he customer has raised an objection that since she is not technical she will not be able to fill her "slack time" with development time...In reality, we just don'...


5

A tool won't save you. Discipline will. Other professionals, such as lawyers, do it all the time for decades, with accuracy, and without a fancy tool.


5

This is a concern I've heard multiple times and the trouble with it is that if it takes a long time, it needs to take a long time. What I mean by that is that the goal of estimation is less about the number in the end and more about driving out understanding. Sure, your team might be squabbling over unimportant details (if every story is a fight over a 3 or ...


4

Your question is how to quantify your estimate to allow management to let Task B start later. My advice would be to set the expectations. You know each Task is going to take around a week. This leaves no contingency and assumes he has no distractions or illness. You could use a Three-point estimation technique to give a Best Case, Worst Case and most ...


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