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


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


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


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

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

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

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

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

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


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


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


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