Hot answers tagged

8

I would recommend to apply a Scrum project approach here. You should define your minimum viable product. You create a larger backlog which contains all project ideas (or user stories). You organise then sprints where you pick the backlog items on which you want to work on next. Trying to track all the goals at the same time will not work. You need to ...


7

I'm sorry, but you are trying to solve the wrong problem. Your team isn't delivering much because your management has no expectations from them to do otherwise. There is a saying in my country that literally translated means "As you teach them so you have them". Management taught this team that nothing happens if they don't deliver much, taught ...


6

Project Objectives are typically higher level than individual Stakeholder Requirements. They usually come first, created up-front in the Project Initiation phase before you've delved in to individual Stakeholder Requirements. Stakeholder Requirements are lower level and more specific that Project Objectives. They'll carefully define the needs of the various ...


6

Mathias' answer is solid. I personally would not go to a full Scrum for this, based on it being a single person project and work in progress is the more critical thing going on here. So I'd stick with a straight Kanban workflow with careful watch on your WIP limits for active work. Essentially you need to tier your backlog. Like a funnel you get deeper and ...


5

A deliverable is a contractual item, whether it is a formal contract between a buyer and seller or simply a promise of a product or service delivery. A goal can become a deliverable by simply putting the goal under contract. However, the taxonomy I prefer is: Goal (an abstract, strategic thing for which we are trying to head) leads to Objective (a more ...


5

To answer your question well, it's important to first address why teams have sprint goals. The purpose of the sprint goal is to focus effort on outcome (the new or improved capability being developed) over output (stories getting done). The product owner should have a sprint goal in mind when they go into sprint planning (which of course may be adjusted ...


5

TL; DR- Tie individual KPIs/OKRs to developmental goals unrelated to the product/project they are working on. My advice is based on a successful implementation one of my own agile mentors did and I hope to do someday with one of my clients. They overhauled the entire HR review process and put in place a 50/50 model. The first 50% of your review is based ...


4

No Scrum upholds the following principles and recommendations that go against this practice. Team responsibility - The team commits to the sprint goal, the individual members commit to the team. Swarming - The team should work together on tasks when possible and sensible. Having 3 out of 4 tasks complete is preferable to having all tasks 3/4 complete. ...


3

The Scrum institute definition of Accountability in a team is: The Scrum Team as a whole is responsible to deliver the committed delivery in time and with the defined quality. A good result or a failure is never attributed to a single team member but always the result of the Scrum Team. In my personal opinion, if the whole team agrees to assign a ...


3

Your question already contains a lot of answers :) However, I have reservations (... as evidenced by the fact that I'm asking a question on Stack Exchange... :) ). Completing stories is generally a team effort and relies on different roles within the team (engineering, design, QA, etc) coming together, so the goal isn't entirely within an individual's ...


3

SMART and WBS/deliverables are two different analytical frameworks. It is like asking whether my daughter is a female or a relative. SMART is (IMO) a quality standard for goals (SMART goals are better than simple velliative goals). Deliverables are a WBS tool; as far as I know there is no formal theory underlying deliverables. There are a variety of ...


2

Objectives are Goals; Key Results are Metrics The term OKR is attributed to Andy Grove (High Output Management. Grove, Andrew. Random House, 1983.). In an OKR, the objective is the expected (or possibly aspirational) outcome, while the key results are metrics for tracking progress towards (or away from) the objective. Wikipedia's overview of the topic ...


2

I agree with others that you're trying to solve the wrong problem, although I do also understand why you reached for "fake deadline" as a tool. It sounds like the underlying problem you're trying to solve is "how can I get the team to generally finish work when they say they will." One thing that has worked for me has been to explain to ...


2

I recommend holding one or two rounds of diagnosis before finalizing the quarterly goals. So basically you can dedicate two or four weeks to just diagnose the source of the performance issues you want to enhance then you may end up with a list of the things you need to do or the fact you need more research/troubleshooting to know more. After you have a ...


2

is it ok to make a developer responsible for a goal in Scrum? Does it break any of Scrum rules? The rules are defined in The Scrum Guide. "They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality" Therefore a single Development Team member ...


2

The general process I've seen work is: ID Ownership. Figure out whose neck is on the line for achieving project benefits. These are the benefit owners. ID Metrics. Work with the benefit owners to determine valid metrics for measuring each of the project's benefits. Every one of the benefits (even soft beenfits) must map back to a valid metric, if it can't ...


2

Don't bother finding the right goal from the stories you picked. It's a symptom, not a problem. It works the other way around: the sprint goal is not an end itself, it's a story picking tool. The sprint goal informs story selection. Why is this a helpful thing? Here's some reading material. TLDR: If you have a clear sprint goal, it's probably also clear ...


2

Assuming that different parts of the team will each work on only some of the projects, how about simply defining numerous sub-goals and assigning them individually to those parts of he overall team. The sprint goal would then be to have each part of the team reach their own goal. Another option would be to break down your setup so that a sprint cannot ...


2

I would say no and I would recommend against using them. What can cause a discrepancies in story points # for individual devs in a team? Someone works mostly on bugs/spikes, so no story points for them. This does not mean they don't perform. Some devs works more than others Some devs are lazy All the above are issues in the team that should be adressed. ...


2

If you're working on an ongoing effort, it isn't a project. Projects have delivery dates/completion dates, and the PM's job is to constantly maintain shared awareness on the completion date. If there are no completion dates, then there should be no PM. If there are no consequences to missed deadlines, then you've transcended the scarcity economy - if you ...


1

First of all: great idea with the workshop! And thumbs up for OKRs! Ad your question: I've made good experiences with having the people who have the needed information plus your team in one room for some time. If your board supports you, this should be possible for at least half a day. So your team and the special department can develop the base for the OKRs ...


1

Since I couldn't accurately forecast the amount of work involved in making the performance improvements I focused my goals primarily around the process of making performance improvements. So, even if we can't control (or know) the amount of work needed to make improvements right now if we accomplish our goal we should be able to make these performance ...


1

Those are some huge and vague goals. I've been using the S.M.A.R.T. approach for years and I wouldn't know where to start with some of those. I can try to give an example of one though to see if that helps: Increase our DevOps Maturity & Sustain a weekly Delivery Cycle for all product areas. Proposed S.M.A.R.T. Goal: By the end of Q3 2017, ...


1

You don't specifically mention Agile, but there are hints of it in there. Even if that is not the operational mode, the following points are still applicable. One of the benefits of properly embracing and executing the Agile philosophy is truly collaborative teams, not a group of individuals assigned to work "together" (i.e. answer each others' questions) ...


1

You may want to consider changing the way you bring work in to sprints. Is it possible to prioritise the work so that the team focuses on one product at a time? This brings a number of benefits: A clear sprint goal A single Product Owner to deal with on each sprint Less task switching overhead for the team (switching between products costs time) Of course ...


1

I'm going to offer an old school answer - you need a work breakdown structure. Define the end product - what will done look like? This is 100% of the work. Aside: I would advise you to do this even if you adopt the other answers. Your comment, I've had a lot of ideas for the aspects of the project that I want to implement makes me suspicious that the ...


1

You are mixing up Goals and Objectives. Goals are not required to be SMART, they are high level, possibly visionary, descriptions of the desired end state. Objectives, on the other hand, need to be SMART. These are the statements that define exactly what the project is tangibly delivering that contributes to achieving the Goals. So the Goal of your ...


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