New answers tagged

0

My problem is that I can't give story points to a story because it's not related to a single technology. Why? The team can give an estimate for the whole feature, they don't need to break it down by technology. If the amount of effort varies across the technologies then the team should use a compromise value for the estimate. This is similar to the ...


-1

I agree with Nacho in principle, but the reality of any [software] project in my experience is that there is a lot of "ground work" that must be very carefully done before anything "visible" can be built upon it. I would treat these preliminary activities as sprints because they're just as fundamental as anything which will follow – no matter what the books ...


0

Either way, you're going to run into problems. Based on my experiences with Jira, each product should be a separate Jira project. That means your iOS application, your Android application, and your web application are all separate Jira projects. I'm not sure what you mean by "backend", but if you are maintaining APIs that are shared among all of these ...


4

We shouldn't call anything a Sprint unless the team is delivering a Done, useable, and potentially releasable product Increment. From my point of view it is a matter of naming, because the reality (at least from my experience) is that this initial stage is a common process in our organizations. The problem with naming is probably setting wrong precedents or ...


1

TL;DR In this scenario for calculating Effort variance, should I consider only effort spent in completing 5 user stories or should I consider the effort spent for all the 10 user stories? You should use only the stories completed. You can't meaningfully measure deltas on effort expended on work you haven't completed. It's worth your while to identify ...


0

Yes – to maybe state it another way: "Constructing and prioritizing the backlog" consists of mapping out the overall structure of the project, considering dependencies within the structure of the software itself, the list of steps probably needed to accomplish certain things, and so on. These are high-level project management and software design concerns. ...


4

Concerning the timeboxes, they are all maximums. If you can accomplish the purpose of the event in less time, there's no reason to remain in it for longer. Your events - all of them - can be shorter than the timebox. The one thing to watch out for is rushing through events and missing the purposes and benefits. Specifically about the Sprint Planning and ...


0

DO NOT EDIT MY ANSWERS! The very-critical thing that I meant to say, at the beginging of the above answer, was this: If your developers need to embark on a multi-step development advance that is of some complexity such that they wish to break it down into milestones apart from "user stories," then I suggest that they should create tests as they are ...


0

In addition, I see from your description that the functionality which your QA team is supposed to test is not on a stable version-control branch that will not be affected by future development activities. Developed material should be added to QA branch(es) and tagged so that QA is always testing against a non-moving target. But also: when you say that "a ...


2

You can't calculate EV on the 10 items yet because they aren't done, so you don't know what the total effort to complete them is. You could calculate EV on the 5 that were completed if you had estimates for those 5 independent of the other 5.


0

The short-answer would be that "hours are only a guess, at best." But if you look at story-points – call them what you will – you are considering the activity map (and the naturally-occurring dependencies within that map) which will eventually cause those billable-hours to be spent. "Computer software," in particular, is a rat's nest of interlocking ...


0

The corporate managers who are attempting to secure the contract should be the only ones to tell you how much planning and advance work you should be doing before the ink is dry ... if any. Because, if for any reason the contract falls through, the entire cost of the effort that you spent is a "sunk cost." They will be obliged to pay your salary out of ...


1

As any work that you perform before the contract is finalized may be lost, you should constrain yourself to only those work items that are necessary to secure the contract. If building an initial backlog helps to create a better estimate and to convince the customer that you're qualified to execute the contract, it might be fine. Otherwise, it's just ...


1

I'd suggest that the best answer is no. Creating and refining items on the backlog is part of business-as-usual - part of the ongoing collaboration between you and the client. Presumably that collaboration starts when the contract starts. Creating the team would have to come first and then the team can have its initial Sprint Planning meeting. Creating a ...


3

The backlog is not something that you create and then is static. The backlog changes - items are added, removed, and reordered - throughout the effort. Unless there is some legal or contractual reason not to, there's nothing to prevent starting the creation and refinement of the backlog before any kind of formal contracts that may be necessary are in place. ...


0

I'd like to add just one more point here. As a Scrum Master / Team Leader, you might well not be the "subject-matter experts (SMEs)" that other members of the team are. While you are the leader of the team, be sensitive always that you might not have all the answers and that you are not obliged to. You can lead a team that's doing something that you do ...


-1

Here's my admittedly-informal use of the term: The "product owner" represents The Almighty Customer, and is often the team's most direct liaison to them, usually reporting directly to them. This role is very specifically focused on what the product will do and for whom it will eventually do it, and for ensuring that the whole thing actually does meet the ...


0

The origin is... Certain methods were developed at software companies and not for IT groups (companies such as Easel or Borland). Thus Turbo Pascal was a "product" that they sold -it was not a brand, Borland was the brand- thus if you lead the Turbo Pascal group you "owned" the product. Marketing did not have a concept of product owner, they centered ...


0

One thing the other answers don't mention is that not all decisions have the same impact on everyone, and for those that don't, you may need neither true (as in everybody really agrees) consensus or a majority vote. For example, say that in a team of six developers, five of them estimate a story at three points and one is strongly insistent that that same ...


4

When we as Agile Coaches and Scrum Masters servant lead teams and help them make decisions, do we need to seek consensus? Yes... and remember that consensus is not the same as unanimity. This is a pretty good article on various approaches to obtaining consensus. I like the Fists of Five technique myself (slightly different from what's in the article)**, ...


2

The preference is that a decision is unanimous. If a unanimous decision is not possible then we may need to consider alternatives. If no alternatives are appropriate then may make the decision by a majority vote. If the decision is by a majority vote it is important that the people voting against accept the outcome. To achieve this we will need: A team ...


7

When “taking it to the team” should we seek consensus? The simple answer is "yes". When people all agree on a decision or an action, they will stand behind that decision or will make efforts to realize that action. The more detailed answer would be that it's not that simple. Sometimes people all agree on something, in which case you have the best outcome ...


0

I personally think that an Agile Coach or a Scrum Master is, and must be, a true "team leader," although one who uses a "laissez faire," or "delegative," management approach. See: "What is Laissex-Faire leadership? Present the issue to the team, make sure they understand it and its implications, and guide them to developing a response by consensus among ...


0

As a user I want to be confident my password is secure so that my account stays safe Sub-task: implementing hashing Sha256 on passwords As a user I want to be able to store both my home and work phone numbers so that I can be easily contacted Sub-task: modify column in a table so that two phone numbers can be stored


0

Not everything needs to be a User Story. Using Feature-driven development (FDD), you write in this format: [action] the [result] [by|for|of|to] a(n) [object] In the case you mention, could be something like Implement hashing Sha256 for password protection


0

And also – the "users" in a so-called "user story" are not necessarily true application users, and they do not have to be. In the case of describing a "backend service," for example, the "user" would be the (whatever-it-is) that issues the SOAP-call to that service. Furthermore: some things, like "implement hashing on passwords," might not correspond to ...


4

welcome! The examples you give are "how" rather than "what". User stories are explicitly about the "what" and the "why" without specifying the "how". So: Why do you want to "modify column in table"? As a user, I want the Username field to have more length so I can enter my entire long hyphenated name in it. As a sysadmin, I want to make the Foo column ...


0

I would suggest that it really isn't your place to decide whether or not someone else finds a report to be useful. As a scrum master you're the informal leader of a team that doesn't have a leader, tasked to lead by persuasion and not authority. But that does not necessarily mean that you are to determine what the team is to do, nor whether a particular ...


0

While looking at the graph I noticed that the sprint lasts longer than you have capacity available. Are the values for sprint length and capacity set correctly?


1

welcome! You're asking a general question with a specific example. I'll try to respond to both. I see several relevant points here: General: you are a scrum master you are new to the org Specific: you think this report is a waste of time the consumers of this report are...? (whether it's the team or the stakeholders might affect how you proceed) The ...


0

When you are designing an API which will be consumed by many business units (and maybe by external customers), a Waterfall approach with fixed and rigidly-stated requirements might very well be exactly what should be done. The business impact of such a layer of software is enormous. "This one scrum team" is only one of the many clients that this layer has. ...


-1

I strongly agree that "teams are not put together randomly." Whether or not your team as composed strictly follows the organizational principles spelled out in "some book," and whether or not you call yourself by a title contained in "some book," the bottom line is that your job is to ensure that the team produces quality software, steadily and consistently....


1

Generally agree with Daniel's answer above, but wanted to expand on his point about team formation: after the project is done the team will be disbanded Good grief, why would anyone do this?? Team dynamics are critical to team-based work, and it takes time for a new team to work through forming/storming/norming to get to performing. I've heard ...


1

I've worked with quite a few organizations that use Scrum like this and I've coached some of those teams, however, none call it "Project-based Scrum". I would highly recommend that you look at the Scrum Guide. It is fairly short and will tell you what is and isn't Scrum. While you will probably get a lot of the benefits, there are a couple challenges you ...


3

This is not Scrum. Scrum has a definition in the Scrum Guide. This is a living document - it's reviewed, maintained, and updated based on feedback from people using it and experiences. This is "real Scrum". Now, what the Scrum Guide provides is a framework. There are a couple of rules. You can add things to Scrum. In fact, you almost have to add things to ...


0

There is no such thing as "the true Scrum", Scrum is a framework, which has some rules / guidelines. How and if at all you exactly follow those guidelines is up to you and your team. If you deviate from the guidelines too much, this usually is called "Scrum-But" which is a short-form for "We do Scrum, but... we dont do X, we do Y in this way, ... we have ...


2

A lot of comments are made about the size of the team and the roles within it, so I'll skip that. My advice (with most questions, issues or whatever): Take it to the team The team is doing the actual work and they can tell what they think they need or should do or whatever. Then you can have a discussion about the situation and come to a solution with the ...


5

First of: thanks for the link to the vanity metrics blog. It was an interesting read. Second point summary: monetize the costs Second: I dealt with the same issue at my previous company. I created the report because I was asked to do it. After the first time I asked why I was creating it because it took some time to create (I could spend 3 to 4 hours ...


0

This Mike Cohn article largely answers my question: https://www.mountaingoatsoftware.com/blog/self-organizing-teams-are-not-put-together-randomly “Management Exerts Subtle Control over Self Organization In the original paper describing Scrum, Takeuchi and Nonaka identified “subtle control” as one of its six principles. They list staffing ...


2

I think you have two issues and the first issue I am drawing the inference just based on what you wrote so I could be very wrong, but I'll take the leap. A high performing team ideally would have a sense of team goals, objectives, a way of driving consensus, and mutual concern of its members among other attributes. I think your first issue is that your ...


0

This Question is best Suitable in context of Leadership skill. Since you are new in team and team is following preconceived mind set you need to apply your leadership skills to convince what is more beneficial? I agree that tool of opportunity cost can help but still how you apply that tool will be more important.


2

I would keep everything in the same project since you are working on a single web app. You can create multiple boards in Jira (one for reach team) and manage each teams workload through these boards. Speak to your Jira Administrator to design the project. The product architecture sounds like it is layered (front-end, product micro-services, etc). Sounds ...


0

Remember, Scrum can be applied to anything, not just software development. It can be applied to fleshing out API requirements too. I assume your entire project does not revolve on this one API call. Just put a priority of fleshing out your API requirements. In this you are your own product owner. Put the API-related feature / code at the top of your ...


1

It is the responsibility of the Scrum Master to make sure the team is following Scrum, but adding a tester to the team does not conflict with the Scrum Guide. However, the Scrum Guide does recommend keeping the team size to 9 or fewer, so it would be worth discussing that with the team. A good approach would be to keep an eye out for issues related to team ...


1

Perhaps it will be helpful to reframe the question. We can ask instead, "Does my team have the skills around quality necessary to deliver the product increment?" You may think you know the answer to this question - you may even be right. However, this is a question for the team. The Scrum Guide has this to say about the development team: They are self-...


1

As a Scrum Master should I decide or the team decide whether they need a tester? This is how traditional project managers talk, not scrum masters. If your team members consider a tester would help and they want a tester, then they should have a tester. The team decides. This directly answers your title question. I'll now say a few things about what you ...


1

Practice swarming Here is a link where Jeff Sutherland, one of the co-founders of Scrum, explain the why and what of swarming. Even though he is prescribing this as a way to improve productivity, I think it will also help to minimize the risk of a "failing sprint". In a typical Scrum team, developers are assigned specific stories to work on. So, when the ...


0

I agree with Thomas but would like to add something small. Sometimes the development team does not have the insight or gut feeling to determine if a sprint wil be met or not. You can help them by visualising the current state of the sprint. For instance with a burn down. In my experience a graph really provides insights to developers, allowing them to take ...


0

I've been using TFS for 4 months now, so I'm no expert yet. But I think the burndown provided by TFS (as I understand it) does not work well. You first need to store the availabillity of all team members and the amount of time they will be available for the sprint. Then you also need to register the amount of time left per task. To me this seems like a lot ...


4

If I would be the leader, I would just say. "Stop it. Don't waste time for this report". Yes you could and this time you may be right. But are you always right? The strength of a Scrum team is that it pools the knowledge and understanding of several people together. Decisions are made by consensus as a result of producing strong arguments or by adapting a ...


Top 50 recent answers are included