Tag Info

New answers tagged

0

If you are faced with the work needing to be re-done, you re-do it. Re-doing the implementation of a product backlog item does not necessarily require any user story to be re-written. The motivation to re-do the implementation may not have had anything to do with a change in the user story. Re-doing some implementation also does not necessarily require a ...


1

One of the main principals of Agile Development is customer being part of the team. It takes both parties to adopt Agile, so: STEP 1 Get the customer on your side before proceeding. Agile is not about your team, it's about collaboration between YOUR TEAM and CUSTOMER. Secondly, Agile is a methodology, it's not perfect, it's not a panacea, it's merely ...


0

Depending on who your customer base is, and how much information you have about them (or can derive about them using companies like Lexis Nexis), one common way of addressing this dilemma is the use of "personas". Basically you build representatives of your customers (some places actually create big cardboard mock-ups) based on data you have. You name ...


0

The way we work with Epics, Stories and Features is as follows Early in the project cycle, we come up with Epics. These are very high-level, almost marketing-centric, bullet-points of functionality. The sort of thing that you can use in an executive summary, such as, Our new web site will allow customers to browse products, view availability and ...


0

(I assume, you do not mean "in Agile", but more specifically "in Scrum" - otherwise asking for "what is the formal method" does not make much sense). If the change is so essential that the work on the sprint, as it was planned, becomes nonsensical, the product owner should cancel the current sprint and initiate a new one (see, for example, here). Of ...


1

Generally, the product owner would create a new story that describe new requirements and you would estimate and prioritize the new story as any other story.


2

At the end of the day, if you're still working on a previous sprint in to week 3, it's still active. Most sprints are designed with refactoring and code review requirements already in mind. If you're coming to find that your refactoring/code review is bleeding over in to another week, I'd suggest adjusting your team's point forecasting to save time for those ...


3

Have you closed the sprint or not? Extending it to a 3rd week sounds like you're still working it, unless you have a week's sprint for code review. Either way... who cares. If all your sprints measure code creation (and all review is done afterwards) then yes, close your burndown chart and start a new one when you start your next sprint. The point of the ...


8

If your definition of done (1, 2, 3) requires that you review your implementation to complete a story, then you cannot take credit for completing the story and the burn down chart does not reflect a completed story. Keep in mind that a user story is either completed or not, and the burn down chart doesn't reflect credit for completing the points until the ...


0

If those maintenance tasks happen without a predictable schedule, why not classify them as incidents? If all you have is a hammer, your task becomes a nail. Alternatively, enter several tasks into your backlog labeled "examine the scripts and update as required." Pull one for each week of the sprint, close them when you've either changed the script or ...


0

Have them also be a teacher It is great that you have a star developer with the best and most advanced skills in the group. I would praise and compliment this. Often such folks are the 'glue' that hold organizations together. I would view the challenge as 'how to get less experienced developers closer to the productivity of the most advanced developer'. ...


3

We have a development and support mode of operation. We follow SCRUM. We have a similar environment where we may not be able to predict what cases/tickets will come during a sprint, so we have allocated 80% of our time in a sprint for development work and 20% for the support work during sprint planning. When we commit during a sprint, we have some stretch ...


3

If you get more of those tasks, maybe KANBAN would be a better alternative, but you seem set for SCRUM, so lets see what you can do inside SCRUM: SCRUM has a so-called impediment list. That's a list of all things that's keeping people from being productive. Such a task has not been planed in the sprint and doing it instead of working on the sprint goal is ...


2

I've certainly experienced this in several agile settings. I would suggest treating the 'rules' as guidelines which allow exceptions and changes from the normal process. If these tickets are already well-sized, i.e. you know exactly what the work is AND you know their priority - apparently most important than I would allow these tickets to be paced ...


2

This is not dissimilar to how we run some of our scrum process. We Estimate stories near the top of the backlog in "story points" Select/explain stories based on the story points that we think will "make up" the sprint Break down the stories into more detailed technical tasks Estimate the technical tasks and compare with the original story points estimate ...


-4

Committed line count is the measure I use. I find it is reasonably reliable. There is a big difference between a guy who is committing 15,000 lines a year and another who is committing 3,000 lines a year, and another who is committing 60,000 lines a year. Back in the day when I wrote a lot of code I maxed out at about 50,000 lines a year. The best ...


2

The purpose of developers is not to "write code". The purpose of ANY engineer, be they software engineer, civil engineer, or whatever is to SOLVE PROBLEMS. Therefore, it IS possible to judge a developer on their work, but not in any of the ways that you listed (sort of...). Number 4 is on the right track, but not quite complete. Judge developers on how ...


2

When planning in Scrum, the first thing to realize is that you should not try to plan the work to keep everybody busy, but rather you should try to plan a certain amount of functionality that your team will try to deliver at the end of the sprint. In Scrum, the input to the planning is the product backlog, which should contain the desired features in the ...


1

Yes, one should divide the tasks by work area expertise. This will allow for accurate resource and project/sprint planning. Let's say after story point estimation you have 100 front end points and 50 back end points over the course of the next few months of 2 week interations. If this were the case, at a very high level one would need to finish equally: ...


2

When the team draws stories during the sprint planning, they should take their available skills into account. That means they might draw a backend-heavy story and leave a frontend-heavy story on the board if they have free backend capacity, or vice versa. If nothing else, some programmers might find time for necessary refactoring. If the imbalance ...


1

If you have zero or very little backend development (or vice-versa), for all practical purposes, you treat that person like you would if she went on vacation or worked on another project. A particular sprint gets the total story points adjusted. From a management perspective, you could treat this as an opportunity to cross-train people with ...


31

You cannot measure and you cannot quantify. Give those ideas up from the beginning. Peopleware goes into great detail about how some people offer value simply by being catalysts for the rest of the team. Those people must not be dismissed because they're not producing lines of code. Likewise, we've all worked with developers who churn out work but are so ...


3

"by the book" - that's your problem. You're drowning in more process than you would have had if you were working waterfalls. There is no 'book' for Agile, there's only the agile manifesto that says "get stuff done without all the overhead". So, if you're estimating sizes and then splitting the stories up into tasks to re-estimate them, then that's a ...


8

You measure it by spending the hours necessary to manage the project. If you wait until all is said and done, you have no way of pulling statistics out of the final product. You can't even look at the artifacts of the process and measure the contribution levels automatically without falling back on the naive statistics. As progress is made during the ...


4

All of the measures you propose are naive and bad, however, some are much, much worse than others. Specifically, the first three are very bad - in fact, trivially subverted. Only the last one - implemented functionality - should even be considered in a business decision. Obviously this measure lives and dies by how well the "functionality measure" maps to ...


3

If that's how your company wants to run their development and have shut down discussion, your choices are limited, or you at least run the risk of upsetting people. Given that the ultimate goal of agile is working software of value, you could try offering to help out by measuirng your team's ability to deliver (points delivered/estimated, bugs in sprint, ...


1

Your actions should be determined by whether the decrease in velocity due to an underestimated story is a one-time or rare excursion, or a trend suggesting your development process needs refactoring. You need better metrics to detect the difference. IMO, computing the average velocity over just the last two sprints is not sufficient. You should be ...


6

As soon as you identify a story that is too large to absorb in the current iteration your team needs to do the following ASAP: Communicate your concern to the whole team. Since you tagged this scrum you need to talk to the Scrum Master and Product Owner specifically, but everyone needs to be aware. Identify what it is that made it take more time. Odds are ...


3

I would assume that your Sprint Kickoff means the Sprint Planning meeting. I think your Scrum Master misinterpreted how this meeting should go. You do not only decide on what stories to develop, you also test them to your team its definition of ready to make sure they don't miss anything (usually using INVEST), and you also subdivide those stories into ...



Top 50 recent answers are included