New answers tagged

2

As @Martin Maat pointed out, you are allowing change of the scope of the user stories during the sprint, that is not a good practice (it can be from PO as well, does not matter). If this happens often it can be frustrating to the team and makes very difficult to plan releases. Putting this aside, we can generalize the situation as in Scrum tasks can emerge ...


-2

Measurements so far based on same set of staff - (unscientific measures): Planning poker - variance off by 24-78% from actual time it took to complete 113 tasks. Historical, data analysis techniques off by as much as 200%. On average, however within 30% of each estimate it took to complete 113 tasks. Commentary- I am biased I admit after the above was ...


0

Scrum does not work well with separate projects that overlap, as you don't have a stable set of people working on a project for the complete sprint. Hence concepts like verbosity etc are likely just to depress you. But first taking the story that give the best cost/benefit to the client, and implementing it including full automated testing, to a quality ...


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 ...


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 ...


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: ...


16

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 ...


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 ...


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 ...


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 ...


0

The mistake management make time and time again is taking the sum of sprint estimates to be the delivery date. In fact, I've seen management set a delivery date in stone before the first sprint has completed. Tools that assist with planning are a means to an end - they shouldn't be a tool to beat the developers with. Estimates are indicators for time-lining ...


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 ...


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 ...


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, ...


0

What comes in and out of every sprint should be pacted and both parts agreed on all the issues/task/items (customer and dev team). So the boundaries and scope of the development is set and it's also the scope of the tests. With tasks pacted dev team can start to design and then to implement. Meanwhile testers (who certificate the release of the sprint) ...


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 ...


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 ...


0

For us, it is just a drill down category for reporting. They save having to wade thru the task description to find out what sort of activity it is. If nobody has eyes on your sprints and aren't creating any sort of reports and the like then it can be tempting to ignore this but it really isn't that much extra work. At a macro level they can be used as an ...


0

"Hammer in a nail - if the wood splits you should have used a screw" How do you know if you're not writing enough tests? If bugs appear further upstream that could have been caught at the unit test phase then you haven't written enough tests. But this aside, I sense you're equally interested in the expended effort as heading off possible bugs. If you find ...


0

Assuming it can't wait and a rollback is not necessary, impossible or undesirable, you split off into two parallel sprints. Of course you need to split your resources to do this but hopefully it's just one dev and some QA time. One sprint takes the current production branch and develops, tests & deploys the hot-fix and only the hot-fix. Because of the ...


0

Roll back the previous deployment and queue the work in the backlog. If you get 'critical' bugs like this its points to a failure in testing, rushing in more changes only makes things worse. You push back the next release, which is in turn rushed through, which leads to more bugs, which pushes back the next release.. etc Roll back the release, take time to ...


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, ...


-1

This is a common issue regardless of whether it is 'proper agile' or not. What you should do is record 8h total against the main task you worked on in a day regardless of how many hours you actually spent on it or other tasks. Estimate in days and multiply by your required hours per day. Round your estimates up to the nearest day. Usually there will be no ...


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 ...


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 ...



Top 50 recent answers are included