79

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 ...


18

The only way to get the milestones accomplished on time is when the team sets either deadline or scope. If someone else does it (a PM), and the team did not participate in negotiation, they will simply think that the deadline is not their responsibility. You can force them to accept it, but they will be set up for failure and they will certainly fail. At ...


17

There is a difference between "impossible" and "aggressive". Setting "impossible" goals, ones where there is almost zero chance of success, is a fantastic way to demotivate your team in the long run because teams are being set up for failure. I've been in companies where the team will provide an honest estimation that a project will take X months to ...


16

Of course it's a management technique. And at the risk of down-votes, it's used all the time. It's a function of Parkinson's Law, also known as the Student Syndrome - work expands to fill the time available. If a team is given two weeks to finish a task that could be done in week, it will take the full two weeks. And before anyone attacks, there are any ...


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

I feel sorry for anyone tasked with maintaining or altering any software created in such a manner. Is it possible to create software like this? Sure. You leave out the following things: Unit Tests Code Reviews Refactoring Architecture Enforcement A team that skips these steps, and gets very good at skipping them can deliver new software at amazing rates. ...


14

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 ...


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 ...


13

Asking the Wrong Question Is imposing “impossible deadlines” a Management Technique? Yes, it's part of the management framework henceforth known as Epic Failure™. It's right up there with flogging a dead horse, deliberately planning a death-march, and telling people to "work harder, not smarter." That doesn't mean it isn't practiced as a ...


11

Framework Overhead All frameworks entail some amount of process overhead. Some of that overhead is in the form of hours worked by the project manager, but some of it is a byproduct of delivering on framework controls and artifacts. The latter form of overhead is often significantly larger, since it tends to impact everyone on the project rather than being ...


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

I don't have any solid evidence - our projects are much longer. At one point I did work for a company that required timekeeping to the 0.1 hour range. That lasted about six months before the accountants told the company President to stick to his own swim lane. Speaking as a PM, I would have the following concerns about timekeeping with a precision of 0.5%....


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 ...


8

Quick answer: It depends. It depends on: Frequency: If you're having a daily meeting, sending the minutes one day later make it useless. Action Points: If you're dealing with several people that will follow the actions discussed during the meeting, better sending the minutes before having the other people doing anything. Otherwise, if the attendees carry ...


8

I recommend: Demonstrate your application to the customer often, and get feedback early. Break stuff down into small tasks that you are very confident about estimating time for. This is key. Focus on minimal functionality first - login, logout, visit home page, etc. before the real features. Use an Agile methodology. Talk to your client daily. Use software ...


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 ...


7

Frequent task switching generally results in inefficiencies, wasted effort, stress and eventually burn-out. I think most people have problems managing this because, generally speaking, they want to be helpful and responsive... and most people are also likely to take ruthless advantage of your helpfulness and responsiveness to get what they want without real ...


7

I am a developer who is studying project management as well. It is a technique, but it is not an effective one if you want a top quality team. Estimates need to come from the developers who are actually writing the code. It is the team lead's job to make sure that the estimates are reasonable to the skill of the developer, complexity of the task and ...


7

You do have a project manager and technical lead on your project. For every project, every project role necessary is represented. In this case, there is only one person filling these roles: you. You have been managing single person projects since you were six. You have more PM skills than you are giving yourself credit for. There are certainly ...


7

I've always billed to the nearest half hour. Tracking to the minute like you do would be extremely demoralizing, especially if I had to account for any discrepancies. Standing up for a healthy short walk should not be penalized. I have often worked in environments where interruptions were usually important and somewhat frequent. Trying to track them to ...


7

When is time tracking too detailed? When you ask the question about why you're tracking to that granularity and no one in your organization can tell you why. We track time in 15-minute increments. Why? Because that is what we've agreed to with certain clients.


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

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

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. ...


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 ...


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