Hot answers tagged

15

Actually, your current way of working isn't that far removed from Scrum as you might think. In Scrum, you also get an initial set of requirements, implement those and demonstrate the result, and based on the demonstration, new requirements can be given to you or the stakeholders can decide that the product is good enough that no further development is ...


7

I dislike Scrum. It has been described as the least agile agile methodology ever. I think its the cause of much inefficiency and a lot of friction between management and development. Understand that all published agile methodologies are starting points for your own modification. Scrap the bits that do not work for your environment, add bits that you think ...


6

I believe you're working backwards here, from an Agile/Sprint point of view. Generally, you decide on the length of the sprint first, as that is the "time box" the work takes place in. Sprints should be a consistent length, so that you can then accurately judge how much work can be accomplished in each sprint--even before they happen. Once you've ...


5

You ask for alternatives so I'm going to say eXtreme Programming (XP). Specifically I think that pair programming might help you here. By pairing people with different skills together, it doesn't matter on what skill: making coffee, testing, training etc. you can spread the skills around the team. But to be honest it doesn't sound like SCRUM is that far ...


4

The main issue is with our backlog, we have a product owner who is also the IT manager. Virtually all of the items on the backlog have really poorly defined stories, nothing has any priority and no one else in the business seems to be having any input into the backlog. This can be summarized as "the Product Owner is not doing his job". This is a ...


4

You aren't really supposed to use time estimations in scrum. One of the core ideas is that time estimations are at best over-specific and at worst just worthless. You estimation story points. A story point is NOT related to time. This is often the hardest thing for people new to agile to grok. Story points combine difficulty, risk and effort into a ...


4

Every one of those outcomes that you described are valid testing scenarios. The way you know that is that each behavior is tied to a different outcome. That makes each one a prime candidate for testing. From a Cyclomatic Complexity point of view, the fact that there are different outcomes for each test corresponding to different program states almost ...


4

While I agree with Thomas Owens answer, I think this needs a more strongly worded answer. The process you describe is completely missing some of the most important parts of agile management and these are the parts that managers should care the most about. (full disclosure: I'm a manager.) In order to improve predictions about when work will be done, ...


4

One of the core tenets of Agile is that it is more important to figure out what works for the team than to blindly follow the rules. Yes, the "rule" is that you never take in work mid-sprint. The reality is sometimes messier. If a critical defect comes in, and maybe a flaw is costing you money, or opening your company up to liability, or leaving an ...


3

As a fellow lone developer, it's difficult to see the need for a lot of things that are more beneficial for a team especially in areas of communication and documentation of time. How much do you want to fine-tune your estimation skills. You may find out there are areas you're not considering (e.g. deployment) or you may underestimate or overestimate some ...


2

Your situation might be a better match for Kanban, since you can start with you have and iterate from there. This means you wouldn't have a big bang introduction which is disruptive to your current projects - just start by visualizing tasks on a board and adopting some of the practices such as retrospectives and daily meetings. You have to be a bit more ...


2

Your company isn't following standard agile practices. Ideally, you shouldn't be estimating in hours. You should be estimating in Story Points, which is a measure of how hard the story is. Hardness takes into account effort, complexity, and other factors. You should then plan your Sprints based on these Story Points and the Velocity (number of completed ...


2

Whether you start fixing it immediately or roll the update back shouldn't be based on the status of any sprint. This item should go on the backlog and you may need to do some sort of mini sprint for a few days or just extend the previous sprint. Fix the problem and don't worry about Scrum too much. The whole point is to be agile and not to arbitrarily stick ...


2

How to make Scrum work for a team with defined roles? Just do it. According to the scrum guide everyone is a developer but back here on planet earth, different people will bring different things to the table. I nearly got lynched when I suggested that some people are really testers while others write the software. Some things you might want to address: ...


2

I've noticed many times a shop will react to an identified problem in their methodology by changing their methodology. This is often the most dysfunctional thing to do. "We keep missing sprint deadlines." "OK, make the sprint longer." This even seems to work. But it really only hides the problem. The methodology will not make you better. It will ...


1

Lets break your problem down to the simplest case. You have one story, one dev, one tester and one sprint to deliver the tested story. If The story is fully specced the dev should be able to complete the work in half a sprint. The tester has no work to do as the dev will test thier code against the spec before delivery. If the story is vaguely specced, ...


1

There's always a trade-off between creation and testing, I could create a perfect product, just come back in 10 years and it'll be ready.. and no manager will ever accept that estimate (or the cost :) ) So you have to be pragmatic, unit tests do not catch all bugs, so you should not try to create unit testing environment that is 100% perfect with 100% code ...


1

Let the issue upset/break into your current sprint This is usually not a popular opinion but: fix the issue. You dropped the ball last sprint. Let it cut into your velocity for this sprint. This will create incentive to not drop the ball again and make your velocity more realistic due to including fixing of issues that do happen. However if it is possible ...


1

When an issue is found, you first do a triage of the issue to determine if it is a really critical "fix now" problem or if it can wait and be planned along with the other work. If the issue really has to be fixed immediately, then you should pull it into the current sprint as unplanned work and track how much time the team spent on it. At the end of the ...



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