Hot answers tagged

27

Should I let them take the test devices home? No For several reasons: Insurance: company property on company grounds is covered by the companies insurance. Company property in the hands of an employee damaging it after hours on private grounds? Might be insured. Or not. You would need to figure it out. Availability: If employees come in one morning and ...


13

Forget what you have and start with a retrospective There is little point in pushing any tools, process or framework unless people are bought in to their use and the reasons behind their use. Book a retrospective with the team and talk through issues. Chances are, if you don't think things are working as well as they could be, other people feel the same ...


12

The answer mainly depends on whether you have enough phones so that if people are using them outside the office nobody in the office will be searching for a phone (and can't find one because all of them are at home). So if you have lots of phones, you can allow them to go home, otherwise, you probably want them in the office all the time, unless there are ...


10

Yes, if they test with it For a simple reason. You need to test your apps beyond the idealized conditions of your testing lab. I can't tell you how many Really Bad apps and websites I have used when the app was clearly only tested on the latest hardware, with an all-internal-router gigabit pipe to the servers, and never "in the wild" with cellular data ...


6

I am a developer of Eylean board tool which offers UI perfection and variety of core features. Features: Task board, burndown reports, cfd reports, lead/cycle reports, time tracking, excel import/export, fully customisable board to match any process, TFS integration, templates, Outlook integration. Structure Server/Client based software, so you can deploy ...


6

In Scrum I have seen physical task boards used for the following: Holidays and planned absences (can be as simple as post-its with names and dates) Burn-down or burn-up charts (updated daily) Team's definition of done Team's definition of ready Product roadmap (giving the team a longer-term vision for the product) Also, the task board doesn't need to be ...


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

Sticky Note planning will be with us as long as people get up during a meeting and start to draw on white boards without thinking. As long as people wave their hands in meetings. As long as they walk up to the projector screen and point at the slides. This goes to the same reason hand written notes are the number one recommendation for note taking. Our ...


4

Cross-Functional Teams, Trust, and Risk Management There are really a number of issues buried in your question. Let me try to address them sequentially, although the order isn't actually important. An agile team must be cross-functional, but that doesn't mean that everyone one the team has the same skill set or level of access. As long as the team has all ...


4

Have you tried using Trello for this? Although we don't have any "permanent" remote workers, we do have several members of the team who work away from the office for months at a time. We have the "Product Backlog" for each product, which the PO maintains and we (as a team) go through this during our sprint planning and pull stories into the "Sprint backlog" ...


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


4

TLDR: It's the Product Owner (PO)'s responsibility to communicate the needs for the product to the Development Team in a format that they can use. I'll address your provided Pros for spreadsheets: All the specifications are in one place and not scattered along multiple stories. It's simple enough to make a filter in JIRA that will give you a report of ...


4

I frequently do not use sticky notes. I use whiteboards and electronic tools quite often. The retrospective is about the team members discussing how they worked in the sprint and identifying actions to take on together as a team to improve. Email as a mode of communication is particularly poor for this sort of conversation because it is slow, lacks visual ...


4

Make a rule for them to ask for it every time and explain why they need a device at home. This will stop them from making a habit of taking devices home for no reason and will give them an option to do some testing outside of work when necessary.


3

Nothing in Scrum says that everyone must be equal. A Scrum team must at least have all skills and permissions required to deliver a done increment of software every sprint. So as long as there are team members with the right permissions, that should be enough. On the other hand, a scrum team should be mindful of its "Truck-factor" and ensure that skills ...


3

Ask your team what works for them If your entire team is in one location, physical wall boards with sticky notes foster team spirit and collaboration. "Our board is more than a tracking device – we stand next to it and have conversations, like the office water cooler. We write on cards and wave them around and move them. It’s a wonderful communication ...


3

No, I don't believe that is possible. Furthermore, I don't see how it could be. Consider the situation where you have two separate 'filter-columns', and a given story fits both filters. What would happen? Would it show up twice? As an alternative, you could just add more statuses - 'In Progress Team A', 'In Progress Team B', etc. Simplest thing to do from ...


3

TL;DR Spreadsheets are great for capturing data. User stories and kanban boards are great for visualizing work or providing conversation placeholders. They can exist together. The real issue is that both can be misused. Neither spreadsheets nor index cards are "features" or "collaboration," so don't treat them that way. Instead, treat them as process tools ...


3

TL;DR Regardless of your role, this is a project management site. I will therefore answer from the project management viewpoint, rather than the (perhaps expected) engineering perspective. Your role as a project manager isn't to justify anything. Your obligation is to raise issues that impact scope, budget, time, or quality in a way that senior management ...


3

First and foremost, you can't use tools to solve this. If there is any problem here, it's a people problem and a communication problem. I say 'if' because this may be fine. Maybe it's something that really only effects them. Or maybe they are, after their 1-on-1, sharing the info with the right people. If you are seeing impacts where info isn't being shared ...


3

From Agile manifesto: Individuals and interactions over processes and tools Your objective is NOT to avoid communication. You want to promote it. People in a project must communicate in the most effective way they see fit. I believe you should shift the focus of your energy, changing the question you're looking for answers to questions such as How can we as ...


2

Depending on what it is you are looking for, i see two solutions: If you want to have some simple progress reports accessible to anyone interested, it probably would be easiest to make them yourself, with something like an excel spreadsheet. Pick out the key points you want to represent, collect the data every week and update your spreadsheet. This way, ...


2

I would suggest to take a look at Eylean Board. It has most of the capabilities and for those that it does not, it offers alternative ones. The reports offered are comprehensive and live, which keeps you to keep track of the team at any time. I am sure you could get exactly what you are looking for out of it.


2

For our project management, we use Eylean. It is not nescecerally created for deveoping project timelines, as it offers more funtions, but with it you can create the exact timelines you described. It offers you a taskboard with all the tasks represented on the board. So the team can see which tasks are waiting to be started, which ones are in progress and ...


2

After contacting Podio Support, at this date, it's not possible to do such things.


2

Analysts are definitely needed in the scrum process. They are both the bridge between the Product Owner and The Team and one of the members of a scrum team. Their main input into the process would/could be by helping the Product Owner by determining the Product Backlog and helping the Team to define the work items, to analyze development work etc. Their ...


2

The best tool, though you could argue about the free part, for me is a whiteboard or flip chart and a marker. Though any sheet of paper and pen will do. It's easy to implement, too. Just put numbers on your cards, draw the two axes and you're set. Start from there and get your process on order first. Once you and your team have established your own flavor ...


2

What Scrum is Designed For Scrum was designed to fit an iterative development model, where each iteration (or "Sprint") delivers a potentially-shippable increment of value. It is also well-suited for projects where time and resources are relatively fixed, but scope is negotiable. What Scrum Wasn't Designed For In my personal experience, Scrum is poorly-...


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