32

Which one is better? The one that works better for the team. That is the entire point of Scrum. Enable your teams to organize around practices and tools that work for them, and stay out of the way. It really doesn't matter what your Agile coaches like and don't like. Their opinion can be used as a basis in your team, but the bottom line is to use what works....


18

In situations like this two important rules are in conflict: don't lie to the client don't look bad in the eye of the client Based on my experience, clients appreciate the outcome of the first rule, so if you are honest and tell them about the background of the issues, they'll most probably understand them (of course, there are client, who will try to use ...


18

"Feature Velocity" vs. Capacity-Based Scheduling Pivotal Labs is making a marketing decision with this design choice. By addressing themselves to "business value" as the key metric, they are implicitly discounting the importance of tracking team capacity or project scheduling in a broader sense. Another way to look at this is that they are trying to sell a ...


17

I know this thread is a little old now, but as a developer at Pivotal, I don't completely agree with any of the existing answers. The philosophy behind not estimating bugs isn't that bux fixing doesn't deliver business value, it's that introducing a defect into the app and then fixing it does not represent net forward momentum. For example, let's imagine ...


14

Why Agile Practices Generally Favor Face-to-Face Solutions [A]fter speaking with Agile coaches it appears they don't like this virtual solution because it breaks the real interactions promoted by the Scrum framework. According to one Wikipedia entry, 2/3 of all communication is non-verbal. In an agile context, this means that in-person interaction ...


13

I won't say that it is all about communication, but I think a large portion of the problem you see can be contributed to communications that could be improved. I work in the same field, and I've seen this behavior from many clients in different industries. What took me a long time to understand was that the way I initially present estimates can have a huge ...


12

TL;DR Don't think "time tracking." Think "cycle time" instead. Kanban Should Measure Cycle Time Generally, Kanban is not about measuring "activities" at a granular level; it is about measuring cycle time for a pull through the entire system. There is legitimate debate about whether this time should include lead time (e.g. time ...


12

I support Zsolt approach, adding one suggestion when planning the way to deliver this information to the users: Before the fix: What caused (a misconfiguration on the application, a typo?) Why it was caused (a last minute requirement change?) why it wasn't noticed (lack of proper testing?) After the fix: Is there any potential similar problem somewhere ...


11

The point of having scrums is to facilitate intra-team communications. From that point, having a physical board is beneficial because it forces people to be in the same room and communicate face-to-face. Remember that something like 75-80% of communication is composed on non-verbal cues, so if you are trying to do things virtually when you don't have to you ...


10

Kanban certifications are definitely not as well established as Scrum training/ certifications. But they certainly are available. The Lean Kanban University, with active involvement of/ direction by 'Kanban Method for Software' pioneer David J Anderson, has been issuing 2 kinds of certifications - AKT - Accredited Kanban Trainer - and KCP - Kanban Coaching ...


10

Your Capacity Planning and Prioritization Processes Need Re-Engineering You appear to be attempting to solve the wrong problem by treating this as an individual-availability issue. This is most likely because you have a weirdly-matrixed organization that isn't based around project teams or team capacity planning, but apparently based on the notoriously ...


8

Transparency and Root-Cause Analysis If you're running an agile shop, transparency should be a key objective. Even in more traditional PM approaches, it's usually a bad idea to sweep issues under the rug. Invisible issues can't be managed by stakeholders or the project management process, so one should always strive for transparency. Address Process; Don't ...


7

You should take a look at Jira Issue Collector. An excerpt from its docs: Need to capture feedback on your website or web application? Want to make it easy for end users to directly create bugs so your developers can act on them? If you develop web-applications or web sites, the JIRA Issue Collector is the best way to turn your customers' and users' ...


7

First: Document Your Process We don't do shopping questions here on PMSE, but we're all about process. The correct way to comparison shop for any tool is to document your actual work-flows and project processes, and then find a tool that supports what you are actually doing. Write down how your team does things right now. If your project is just forming, ...


7

You should estimate bugs and non-functional requirements I am not familiar with Pivotal Tracker. However, looks like your question is more general: Should I not be estimating bugs? Should I not be estimating technical debt or non-functional requirements? I think this is what you are referring to as "chore". In my opinion, you should be estimating these. ...


7

This is about span of control. And there are rules of thumb to help an organization decide when it is time to put in a layer of control. Of course, there are competing and contradicting schools of thought on this. You need to research the benefits, costs, and risks of different approaches to see what fits best in your organization for this project at this ...


6

Certifications are (Just) Sales Tools [D]o you find this kind of certificates any useful? Do you think, that candidate with such certificates (assuming the same achievements and experience) have any advantage over the others? While I won't address the state of available certifications (as I consider that a searchable question with non-canonical answers) ...


5

More than probably your task is set by default as "Fixed Units" so the initial 22 hours of work are not kept fixed. Now 217.13 days * 8 hours/day = 1737 hours (the task duration in hours) Whenever you add a new resource in "Resource names" column MS Project tries to guess what you want to do. And by default he believes you are adding a new resource with ...


5

Well based on Trac's website docs... "Component — The project module or subsystem this ticket concerns." The Trac Ticket System Hope that helps.


5

I've worked on teams using both methods, sometimes at the same time. Others have mentioned the reasons for preferring the real world scrum board being about physical interaction and in-person communication. Personally, I prefer virtual scrum boards for several reasons. First, as you mentioned, distributed teams or even simply working from home days. In ...


5

There is a difference between estimates and planning values and I find most either ignore or confuse the two...probably the latter. Work effort is probabilistic and a proper estimate should reflect that and be provided as a range of possible results. For example, an estimate to build a wall might be six to 15 days, most likely nine. If you built that wall ...


5

Don't use any software right now. It will only constrain you. What you need is: A large wall Several packs of 5x7 Post It Notes (Staples or Office Depot) Several packs of regular Post It Notes A roll of blue painters tape A butt load of Sharpies and colored markers **Planning Process- Agile Product Planning Outline I've shared a detailed white paper ...


5

You're solving the wrong problem. If the scope is ambiguous and uncertain, then you need to pursue a type of contract consistent with that situation. Do not enter into a contract when no one knows the scope where you share or take fully the cost risk. Simply say no. Enter into a T&M contract, where you can never lose money due to uncertain scope. If ...


4

As a freelancer you need a personal task manager with ability to track time in order to bill your customers. I would suggest Eylean board as it is free of charge for personal use and it contains integrated time tracking alongside other cool features for effective production.


4

A popular package is OnTime but it is really scrum / agile oriented. Other candidates are Trello, DevComplete, and good old Borland does nothing else these days. One of my favorites is YouTrack which actually started out as a bug tracking system but is moving more towards a project management system. It is free for 9 users and 3000 issues with some other ...


4

Define Your Process, THEN Automate It One of the (open) secrets of managing any process is that if you can't do it manually, then you can't automate it. Or, to put a more positive spin on it, solve your problem with whatever process works, and then automate that process to whatever extent is practical. Getting Down to Specifics In your case, you say: ...


4

Before going into a system that offers the segregation between a task and an issue, would like to make sure the users are very comfortable with the terminology and, more specifically, when using one or another. As you pointed, systems usually use the same nomenclature for identifying something outstanding. I believe that's mostly because users don't care ...


4

Scope - having just sat through a 30 minute phone call that managed to decide "we don't know what the manager wants, and we're afraid to ask him, but we're going to try to deliver it to him anyway", I have a great deal of emotional investment in the fact that "unclear requirements" are one of the top three causes of failure. Dependencies Todo lists don't ...


4

I think the answer to your question is a disagreement with your basic premise: updating tasks with estimated hours is not necessarily a "Scrum best practice." Part of the point of Scrum is to use accurate and empirical data to provide accurate estimates of the amount of work that can be accomplished. In my experience, the best practice is to use User Story ...


4

It sounds like you're operating in chaos, with purposeful loose change control. I am not sure a tool or method is the right solution but rather resetting expectations on what you are able to forecast and promise by way of delivery. If you are in constant flux in terms of your timeline and cost accrual against specific projects, there is no way you can ...


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