12

To your overall question, while Scrum can be applied in most projects, it is not necessarily the best approach for some projects. That said, it is well suited to complex problems that require discovery of the solution and adaptation to new information. Your project sounds like exactly the kind of project Scrum was designed to tackle. However, you raise some ...


7

I think there are two questions here. First: Can the Development Team formulate new suggestions from this site? YES! You can make a weekly or biweekly meeting (name: Grooming) (time box: half hour) where you can collect all new suggestions. Second: Can the Development team vote for or against certain suggestions? NO! It will be better to push ...


6

Embed Skills, Not Individual Roles Ideally, all product development resources should be intrinsically part of the Scrum Team. That makes any team member developing the product a co-equal “Developer,” regardless of variant skill sets within the team. A product-design focused Developer should be treated as an integral part of the Scrum Team, rather than a ...


5

I don't think there is a "correct" way to do it. If the client wants to see the payment feature in the beta, then they want to see it. There is no project management method to tell them otherwise. I can understand your wish to take small steps, but that just means you will need to build the beta in small steps (i.e. features first, payments later). If the ...


5

Assuming the employees working on the application actually use the product as it's being developed, as in "eat your own dog food", then they surely have useful input. If they are simply coding, testing or documenting the system then their vote would need to be accompanied with a good business case as to why they want the feature added/removed. Otherwise, ...


5

Is Scrum actually suitable for all kinds of projects? Like with many things in the software industry, Scrum is not a silver bullet. It works nicely for some types of projects, and less so for others. I've often seen the Cynefin Framework mentioned when trying to identify projects types where Scrum might be used, so maybe have a look at it and see under what ...


4

Voting will depend on their usage of the application and how priorities are defined. Suggestions of new features are always welcome, regardless of the source of it. It's still important to understand the purpose behind it. In the majority of the cases, such proposals are either to improve overall application usability or to automate some processes. Once ...


4

What you need to do is some Project Management. Start with a Task List - a simple Excel Sheet will do. or use an online tracking system like Trello. You need a few columns: Priority - a numbered list where the top item is always #1, the second #2, etc. Task - a short description Duration - how long it'll take. If you standardize to hours or days, you can ...


4

How is your 'rejection workflow?' If you need a workflow to handle rejected user stories, then you have a problem. Normally, a user story being rejected should be an exception; someone misunderstood something, someone made the wrong assumption, someone failed to communicate... it happens. Nobody's perfect. But when it happens it's something that it's ...


4

Adding a bit to Daniel's excellent answer. You say: all the work is deeply technical and has no user facing consequences But you also say: focused on improving the performance of the product as a whole I can think of two reasons why you might improve the performance of the product: To improve the user experience (quicker response times, etc.) To ...


4

TL;DR The Scrum framework can usually be adapted to any product or service that can benefit from time-boxed effort and incremental delivery. That doesn't mean it's the best fit for every project, but the original question does not describe anything that can't fit into a Scrum implementatation. Question Analysis The question, as currently constituted, ...


3

Disclaimer: This comes from my experience on the financial sector. It may or may not be applied to other areas, as some expressions are very common on specific industries but not used in others. Fire-fighting management. As described by this hbr.org article, firefighting is the working "model" where Managers and engineers rush from task to task, not ...


3

Analysis Your current process contains a large set of agile anti-patterns. Some of these process dysfunctions include: "Testing" divorced from a Definition of Done (DoD). Lack of test-first development. Sequential (rather than collaborative) activities. Treating changes (other than DoD gaps) as rework rather than new work. While JIRA's ticketing model is ...


2

From the looks of it, you currently don't have a team. You have a group of developers presumably working in the same office. To turn them into a team, you need to get them to take collective ownership of the unsliced work-items that provide value to the business. A few suggestions in that direction are Hold a retrospective with all team members about how ...


2

Management by surprise. One thing you might try is each time your boss comes in with new urgent tasks you ask him: "Which of the tasks we have already agreed on should I drop in exchange for the new one?" https://www.vitalsmarts.com/crucialskills/2015/01/dealing-with-a-last-minute-boss/


2

To put it bluntly, from a commercial perspective people only care if you deliver the project they requested within the time and budget you promised. I have intentionally chose the word "promised" because if you don't do a proper job at communicating things, people that don't understand how the project is built will take things as a promise. And when the ...


2

By this brief description, it sounds like you company is busy, has a strong client base and healthy demand; it sounds like your company is staffed lean and mean; and deadlines are not a critical success factor, i.e., your clients are still providing a healthy demand despite their work being delayed. Perhaps your company is bringing in a healthy profit, as ...


2

TL;DR You perceive this as a scope problem, but in all likelihood the underlying problems have more to do with how you visualize the work, how you collaborate with your development team, and how effectively you set the expectations of your stakeholders. You should adopt an incremental, iterative approach that allows you to deliver features in almost any ...


2

There really is more than one question here. How to organize in an environment where you need multiple skills How to hire people when you don't already have expertise in-house How to evaluate people's performance Let's try to answer these in a concise manner: How to organize in an environment where you need multiple skills Use cross-functional teams. If ...


2

When you receive a bug report, it needs to be triaged. The workflows that I use tend to look something like this: Review the bug report and confirm that it truly is a bug. Some people who report issues may not be aware of the intended behaviors of the system. The issue reported could be acting as designed. Assuming that the issue is a bug, check the quality ...


2

Simply putting, you can't. What is a Service Level Agreement? A Service Level Agreement, as the name says, is an agreement stating how a (already existing) service is going to be provided. SLAs are useful to set the minimum acceptable service levels against specific metrics or Service Level Objectives, such as response time (how long users will have to ...


1

I found "state of perpetual emergency" used in multiple contexts to describe this. An article that I recommend that describes this in the context of software development is "Catch the Pig!". https://pragprog.com/magazines/2011-05/catch-the-pig Ask: "Do you think that there will be a day any time soon that is less busy than today" to get work done? So: "...


1

The Product Owner doesn't need to care about Tasks. You should not be creating them. You should not be looking at them. You should not care about them. You create and prioritize the Stories. The Team then creates Tasks and Sub-Tasks. The Team must update Stories when they finish working on them. There is no such thing as a 'half-finished Story'. A Story ...


1

It is sometimes misleading to have a "manager" title without having real-life experience in project management. Even if it is not stated in your title, if you can show and materialize your past experience in either one of the five main process groups, then PMI will not worry about the lack of a "manager" title. You're good to go. All the best.


1

What does not matter: - Your job title; - Whether you managed a project end-to-end; What does matter: - You had a leading/directing role; - You have experience with all five main process groups (being Initiating, Planning, Executing, Monitoring & Controlling and Closing). Please find more explanation in the PMP Handbook on the PMI site.


1

You can find the PMP criteria on PMI's website. The criterion you seem to be struggling with is the experience one, in which PMI requires either 7,500 or 4,500 of hours (depending on your college degree situation) "leading and directing" projects. That criterion does not use the word "manage" or any of its derivatives nor do any of the criteria require a "...


1

My approach would be to send the list first and get the ranking (1 to 10) order, sit and order the requirement based on the ranking and call for a meeting with all participants, discuss and go for a ranking negotiation that enhances the understanding of what customers really want.


1

I suggest using the MoSCoW prioritization; e.g. ask them these questions for each feature: Would we have problems if this feature doesn't exist in the product? (y/n) Yes: Can we have a workaround for the problem? (y/n) No: How much relative value does it add? (1 to 10) For a single answer, YY is a must-have, YN is a should-have, and N is a could-have. For ...


1

From my experience, I recommend the Buy a Feature game. This works best if you can get all the stakeholders in the same room, so that your stakeholders have a chance to discuss their opinions. Putting a virtual "price" on features helps you to adjust the prioritization to the relative effort that it takes to implement a certain feature.


1

One way would be to set up a quick survey - there are sites that let you do this for next to nothing. Rank each feature between 1 (must have) to 5 (hardly necessary). Or else "Yes, Maybe and No" Else you could send each a spreadsheet and use a clever macro to merge the results. I think you'd get more accurate results if you ask them to choose their top 5 ...


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