Tag Info

New answers tagged

0

I have to disagree with the top answer of assigning story points to bugs. Story points should be for new value being delivered. If you are going to assign points to product value and non-value items, you might as well just estimate and track hours. Bugs are the overhead of what you did yesterday and is not indicative of the velocity of product completion, ...


1

There is no hard and fast rule on who to invite to the retrospective. The right answer will almost certainly change on a retrospective-by-retrospective basis. The right answer also depends on many things: The relationship between the PO and the team The relationship between stakeholders and the PO The relationship between your manager and your team The ...


1

In the scrum process the tasks are estimated at the sprint planning meeting, Product owner presents the top priority items from the backlog Team does the effort estimations for each item Depending on the time box certain items may be moved to the next sprint or more items may be added to the current sprint. Read more from : ...


0

This should take place in the planning game. Armed with the estimates and business priorities, stories are selected for the upcoming sprint.


4

Typically, teams hold backlog grooming meetings during a sprint to discuss and estimate the items in their backlog. Having at least the highest priority portion of the backlog estimated before the planning meeting makes planning for the next sprint go much more quickly. It lets the team focus on which items will be part of the next sprint rather than getting ...


0

I believe the concept of "Sprint 0" which might typically be a longer initial sprint covers this, doesn't it? Here's an article (What is Sprint Zero?) that I think describes what should be done in Sprint 0, including sufficient initial design to facilitate emergent design in subsequent sprints. The article describes some of the common misperceptions and ...


0

When I hear this argument against Agile versus waterfall, it sounds like they envision the history as, "We create these great specifications that the clients love because all of our projects are always on time and budget, but if only we could be lazy and accomplish the same thing without having to write requirements." That's not the way I ...


5

how can I best allocate work in initial sprints to catch the (probably inevitable) architectural issues in the solution as early as possible? By not mistaking quality of planning with quantity of planning. The entire point of agile is that planning is inadequate. Business people don't really know what they need until they can have customers try it out. ...


0

Grooming and spikes is the way we addressed this sort of thing, not always successfully I might add, all depends on how (of even if) the stories are written. We also have a dedicated architect, well some time from them. So in grooming people familiar with the backlog and the proposed architecture should be looking at how a 'new' story impacts what has or ...


5

The first mistake that often gets made is that people donĀ“t look beyond the stories in the current sprint. While it is correct that those stories are not in scope now and might change or be removed at a moments notice, completely ignoring them when making high-level design decisions is a nice route to chaos. When making high-level design decisions, you must ...


2

Many agile experts recommend starting new projects by thinking about what they call the "Minimal Viable Product". What this means is we stop thinking about all of the features an application should have, and instead ask "what is the smallest possible thing I can build that would be useful". Given your example above, I would suggest starting by forgetting any ...


0

You are a software developer! Don't answer misleading questions! Instead, help your manager to ask the right question. Then, answer the good question. When will my feature be ready? is a misleading question. Examples of good questions are: What's the probability of having my feature in three months? What's the date by which I will have my feature ready ...


1

I am somewhat puzzled; please bear with me. It would appear to me that you are in a pretty ideal situation that most dev managers can only dream about! You have fixed scope (who has seen in that in this day and age of constantly changing business requirements?!), you have a dedicated team (ditto!) and you have experience working with the team - so their ...


0

Triage the scope, so that the most important features/requirements are completed first. Make the project "releasable" at least every week or so, so that if your funding is cut off mid-point, you don't have a complete failure. By the way, this is standard practice for experienced development managers/leaders, as it is rare to finish everything by the ...


1

As mentioned in the comments by @Snowman, your project idea is far too big and unfocused. I would suggest you decide on an IDE (either Visual Studio or Eclipse, depending on your language preference) and implement a Video Chat plugin, most likely just an integrated browser view using Google Hangouts.


0

It's probably easiest to do this on your local machine, and the publish it to the cloud. Client/Server technology is not that hard to develop on a local machine. Programmers do this all the time when developing web applications. Assuming that you are developing a dedicated UI that doesn't use a browser, all you need to do is run the server side as a ...


-1

I have worked in an organization where the term user story referred to the format in which you describe the features (software functionality) and stories (detailed features that are small enough for a sprint backlog). This definition does conform the rule: feature == user story and user story != feature.


0

A Sprint usually starts when the story is clear - at this stage the Product Backlog is established and prioritized. If you started without having the design than it should have been clear what can be done without the design and what not... If you have to improvise while the design is 'bumping' between the client and PO than your PO has to inform the team ...


2

We track the time spent in the sprint iteration for capitalization purposes, (hours burnt on tasks related to a user story), and move the pointed user story along if the goal of the PO is to keep trucking on it during the next sprint, leaving points the same. If the PO's goal is to move something else up in its place, then we'd simply put the unfinished ...



Top 50 recent answers are included