Search Results

The good news is that all of the same techniques work in short projects as longer ones. I've done a number of week-long projects. When we did it, we usually did either 2 stand-ups per day or just one …

There are real challenges when doing paired programming, but I don't think there are usually "bad projects" to do it on. The classic argument against it is the work where you "know what you have to do …

First, in the comments you said that you're thinking about the agile manifesto itself, not a framework like Scrum. The agile manifesto contains 4 value statements and 12 principles. … There are cases where the agile manifesto may be too difficult to follow all at once in an organization. For example, one of the principles states "Agile processes promote sustainable development. …

I notice your question is tagged as "Agile", so I'll assume you're ok taking that approach. If you create a prioritized backlog of work to be done, work from the top and just pull stories in. … If you want to get a better feel for scrum, ScrumAlliance and Scrum.org both have good info and I'm personally a big fan of this book as an introduction: Agile Project Management with Scrum by Ken Schwaber …

Product Backlog The Scrum Guide says a lot about the Product Backlog, but here's a short piece that's a good start: The Product Backlog lists all features, functions, requirements, enhancements …

Here is how I always look at it: The items on the right should serve the items on the left. Individuals and Interactions over Processes and Tools We have all known processes or tools that help us …

Your understanding of T-Shaped skillsets does not match mine. What you describe is trying to make everyone an expert, which is absolutely unrealistic. I feel a more accurate example of T-shape in what …

When I look at the Agile Manifesto, I reading as the things on the right serving the things on the left. For example, there are release approval processes. … So, applying the Agile Manifesto, we'd want to look at this process and ask ourselves how we turn it back around, either getting rid of a process that has outlived its usefulness or revamping it so that …

This is often true for agile teams too and that mindset needs constant tending. …

Scrum promotes an iterative, incremental, and adaptive approach to releases. In effect, what you are asking is if you are taking this approach and the answer is probably, possibly, and likely not. I'l …

It sounds like you are doing something very common in teams - a 2-week waterfall project. Things likely move from some requirements conversations before the sprint or in the early days of it to coding …

It sounds like you might be mixing up the interaction between Product Backlog and Sprint Backlog. The Product Backlog is all of the items the team knows about that might need to be done. My guess is t …

This is a pretty classic problem in multi-tier applications. First thing I usually do is split off the front-end part of the work, so something like: As the player, I would like to disable users t …

As a general statement, you should plan based on demonstrated velocity. That doesn't mean you can't try to improve your velocity over time, but this is usually not an overnight change and in my years …

If you have a consistent scrum team and sprint lengths (both of which you should if you're operating in the Scrum model), you should have a consistent sprint cost. If you have other skills that are ne …