I'm about to start a new development project that our company would like to run in an agile manner. At this stage I am the only developer but it is expected 1-2 more will join in future sprints. Given that we have been doing a lot of story elaboration discussions in preparation for our first sprint.

As part of the elaboration we have estimated the tasks using story points so that the PM could give a quote to the customer. Part of the discussion required putting an hour against points so it could be converted to a cost. From this, our PM has determined how many points are to go into the sprint given how many hours we have as a development.

I have suggested to the PM that in order to meet each sprint as best as possible the development team aims to complete the last story at least 1/2 a day (or full day?) ahead of schedule to give the testing team time to test and then subsequent bugs fixed (as required). That is because we have included testing in our definition of done.

However, he did want that as he didn't want developers sitting around doing "nothing" so to speak. I thought that was unlikely as there will always be "bug fixes", "refactoring", "code review", "design discussions", "other work", "spring planning", "Sprint retrospectives" etc that could all fill in the day if required.

Is this an acceptable request? How do other development teams ensure they meet a definition of done that includes "in house testing complete" within a sprint.

3 Answers 3



Question 1: "Is [finishing early to allow for testing] an acceptable request?"

Answer 1: It is completely reasonable because in Scrum, the Development Team is self-organizing:

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality - Scrum Guide

This means, you choose the way you work. Period. If you think finishing 1/2 day ahead is an improvement, then you should do it. This is the Development Team practicing self-organization by solving its problems itself.

Question 2: How do other development teams ensure they meet a definition of done that includes "in house testing complete" within a sprint?"

Answer 2: They decompose work into small-enough chunks and ensure they are cross-functional:

...with all of the skills as a team necessary to create a product Increment - Scrum Guide

Cross-functional means, the team should posses all the people, skills, tools, etc it needs to make work "Done" within a Sprint. In your example, this would mean testing skills, tools, and maybe QA people are needed on your Development Team.

As they get better, they shorten and amplify feedback loops in their development processes and strengthen their cross-functionality by learning new skills from each other.

Bigger Fish to Fry

There are bigger problems than needing to complete testing work within the Sprint. In no particular order:

You've got a Project Manager, not a Product Owner This person is quoting to a customer in hours, mapping those hours to story points and planning Sprints for the Development Team. God help you if this translates to a fixed scope, fixed timeline situation. The Development Team and/or the Product Increment may not survive that sort of ordeal. This is a formula for cutting quality to meet a deadline or death-marching to a date everyone knows can't be hit.

The Development Team is not Cross-Functional If someone outside the Development Team has a big red button that can make work un-"Done", the entire planning aspect built into Scrum becomes unreliable and seriously un-empirical; the Scrum Team can't know how much work it can get "Done" per Sprint and can therefore not create forecasts, form Sprint Goals, plan releases, etc. This is a serious problem, and a fundamental divergence from the lean manufacturing theory that spawned Scrum.

Absent/Weak Scrum Master? I haven't inferred whether you have no Scrum Master or a Scrum Master who is weak or just very green. I say this as a Scrum Master who started out as green as green could be and who struggles daily to act with needed courage. If this SM exists, she/he should be fighting tooth and nail against these practices, removing what are massive impediments to the Development Team's progress, and shielding the team for metric weaponization and micro-management. Moreover, the Development team needs to expand to include as many other developers (QA are developers in Scrum) as are needed for the Development team to create increments of "Done" work in a single Sprint.

This is at a minimum. There are several improvements (s)he need to actively coach into being by serving the Product Owner, Development Team, and the Organization as a whole. For more on this, check out the Scrum Master's duties section of the Scrum Guide

I Know That Feel Bro

This stuff is hard, and it takes courage. I tell you these things not to make you feel attacked for trying but rather to encourage you; you stand to be terribly discouraged when you make nominal improvements to a Definition of "Done" but are being forced by to work to deadlines that deny you the craftsmanship of creating quality product that solves real problems for real people.

I've been there (and am there still in some ways) and want to encourage you by revealing that are likely root causes to the dysfunctions you initially brought to this exchange. I hope you find this answer is helpful on both fronts.

  • Thanks very much for the feedback. I have a feeling this might be a fixed price / quote project but am hoping it's not quite like that.
    – dreza
    Commented Jan 6, 2016 at 0:56

How can you "[aim] to complete all the tasks ... ahead of schedule"? Don't you have tasks to test the software? Did you mean "aim to complete all of the development tasks"? If the latter, that's probably correct -- you should indeed plan to finish all development early so that there's time for testing, and fixing bugs found during testing.

If you don't have testing tasks, add them. Scrum is about being honest about the effort required to finish a piece of functionality. Testing takes time. So does documentation, maybe even training and communication if other teams are depending on work that you're doing. In your definition of done, "done" needs to truly mean "done". The sprint planning must allow time for writing code and testing the code. If you don't plan for it, it will happen anyway (or you'll deliver untested code).

Bottom line is, the team as a whole is responsible for delivering functional, tested code. As you suggest, if the developers are done a day or two early and there are still testing tasks to be accomplished, they should be helping finish the testing tasks.

Another thing to think about is that scrum isn't about optimizing the work of each individual, it's about optimizing and planning / predicting the work of the team as a whole. If some team member goes idle, there's nothing inherently wrong with that as long as the work gets done according to the plan. Better to have someone with nothing to do than to miss the sprint target.

How do other development teams ensure they meet a definition of done that includes "in house testing complete" within a sprint.

The answer is surprisingly simple: make sure you have sufficient testing tasks spelled out in the sprint planning, and make sure everyone on the team is involved in finishing all of the tasks.

  • Yes sorry I mean development tasks, I'll update the question
    – dreza
    Commented Jan 5, 2016 at 21:16
  • And no, we don't have explicit testing tasks identified as yet
    – dreza
    Commented Jan 5, 2016 at 21:26
  • @dreza: then that's part of the problem. Unless you have magic testing fairies, testing takes time. You must account for that time. Scrum is all about being honest and open about the amount of work required to deliver a story. You potentially need tasks for development, testing, documentation, possibly even training and communication. These things all take time. Spell them out completely, put all of the cards on the table. Commented Jan 5, 2016 at 21:29
  • ha fairies, yes that is indeed what they are here :) thanks for the inputs
    – dreza
    Commented Jan 5, 2016 at 21:32

You should ask your company why they want to run the project in an Agile manner, because like the above posters explain there is nothing Agile about the testing or project management practices described in your situation.

Get clarification on what an Agile manner means to your PM, the customer, and other stakeholders driving the project before you get committed to working on the project, or buckle up for potential death marches, sh*ty quality code, and pissed off customers that don't want to do business again.

Agile projects should be sold on the capability of a team to deliver what is most valuable to the customer and change what is delivered as the team and customer learn more. Selling fixed scope/budget is not Agile. Agile is not just about how the development team operates. The whole organization needs to be Agile to support agile teams and projects.

As far as I can tell, your PM is running a waterfall project using some Scrum terminology. That's very confusing, and its better to be explicit (for both you and the customer) about the tools and processes you will use to deliver a project rather than pretending to do something under specific methodology without understanding what it means or really doing it.

-Story points on tasks is not Agile-Scrum

-Converting story points to hours is not Agile-Scrum

-Quoting on fixed scope for a fixed budget is not Agile

-Having dev and test teams be separated defeats the concept of a cross-functional team and is generally avoided in Agile organizations

-Where's your scrum master in all of this?

-Its ok to have free time on Agile teams, its when continuous improvement happens.

-A PM that is trying to keep an Agile team at 100% capacity doesn't belong on an Agile team. The team sets the forecast and is empowered to balance customer work with continuous improvement.

  • thanks for the feedback. to answer some queries. 1. Our Scrum Master is also our PM (small company, multiple roles/hats). 2. The customer wanted a quote for the whole work so we had to do this somehow. Converting the points to hours was the only way we knew how.
    – dreza
    Commented Jan 6, 2016 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.