E007 Agile Methodology is recorded under banner number ITEC 2201 and carries 3 competency units. It covers agile principles, practices and mindset through three lenses: scrum, Kanban and Lean, with the emphasis on adaptability, collaboration and delivering value in increments rather than at the end. E007 and ITEC 2201 are the same requirement. The course rewards students who can say what each practice is actually for, and it punishes ceremony described without purpose.
Three approaches with three different problems in view
The quickest way to hold this course in your head is to notice that scrum, Kanban and Lean solve overlapping but distinct problems. Scrum organises work into timeboxed increments with fixed roles and events, which suits work where priorities change and a regular cadence of inspection helps. Kanban visualises the flow of work and limits how much is in progress at once, which suits a stream of arriving requests where a fixed cadence would be artificial. Lean is the older idea underneath both: identify value, remove what does not contribute, and shorten the path from request to delivery.
Once that map is clear, comparison questions become tractable. A support team drowning in simultaneous tickets is a flow problem, so limiting work in progress helps immediately and imposing sprints may not. A product team with a shifting backlog and stakeholders who need predictability benefits from a cadence. An assessment scenario nearly always contains the clue that decides this, and finding it is more useful than knowing every ceremony by name.
The mindset element sounds soft and is scored seriously. Agile approaches assume that requirements are discovered, that feedback is more reliable than prediction, and that a team should be able to change direction without being punished for it. A submission that adopts agile mechanics while describing a command structure where nothing can change reads as contradictory, and evaluators notice the mismatch even when every practice is correctly named.
Outcomes are logged as Competent or Not Competent, since WGU issues no letter grades and holds no ordinary grade point average, with 3 competency units describing its share of a flat-priced six month term. Closing this one early is straightforwardly worth doing, because it is a course where preparation transfers to later project work.
From aspects to a practice-by-practice plan
If your version of E007 uses a performance assessment, the aspects usually ask you to apply agile to a described situation rather than to summarise it. WGU requires a score of 2 in each aspect for a task to pass and scores aspects independently, so a strong scrum section will not carry a Kanban aspect answered in one line.
Budget before drafting. Take a rubric with six scored aspects and a target near 1,750 words. Reserve 130 words to set out the team, its work and the pressure it is under, and 100 for a close, leaving 1,520 across six aspects, or roughly 253 each. Weight by demand: two aspects that ask you to recommend and justify an approach need 360 each, because each requires criteria, an option comparison and a decision. The four remaining aspects, which ask you to describe or apply a practice, take 200 each. Two at 360 plus four at 200 is 1,520 exactly.
Within each practice block, answer three questions in order: what problem this practice addresses, how it would run for this specific team, and what would tell you it is working. The third question is where most submissions go quiet, and it is the one that separates an applied answer from a summary.
Where an aspect asks about roles, resist listing them generically. Say who in the described organization would hold each role, and name the conflict if the obvious candidate already has a competing responsibility. Real teams have those conflicts, and acknowledging one is a strong signal of applied understanding.
Shape for an agile adoption analysis
E007 deliverables usually analyse a team's situation and recommend an approach. These proportions fit that document.
| Section | Content | Share |
|---|---|---|
| Team and demand | Who the team is, what arrives at it, how predictable that arrival is, and what currently goes wrong. | 12 percent |
| Selection criteria | What an approach must do here: absorb change, improve flow, add predictability, reduce handoffs. | 12 percent |
| Approach comparison | Scrum, Kanban and Lean thinking measured against those criteria, each with what it assumes. | 22 percent |
| Recommended practice | The chosen approach described as it would actually run: cadence, roles, artifacts, limits. | 21 percent |
| Collaboration and roles | Who holds which role, where authority sits, and how decisions get made mid-increment. | 14 percent |
| Measures | What you would track to know it is working, and what you would deliberately not track. | 12 percent |
| Close | First change to make, expected effect, and what you would review after two cycles. | 7 percent |
Sourcing an approach with a lot of commentary around it
Agile has more written about it than almost any topic in this degree, and most of that writing is consultancy content. Principles and values should be sourced to the original published statements and to the recognised guides that define the frameworks, not to a blog restating them. Where a framework defines a role or an event, quote the defining document, because these definitions are precise and the popular paraphrases have drifted.
Claims about outcomes need a different source entirely. Statements about delivery speed, defect rates or team satisfaction under a given approach are empirical and belong to published research or survey data with a year attached. A framework guide can tell you what a practice is for; only evidence can tell you what happened when organizations used it, and conflating the two is the most common sourcing error in this subject.
Be careful with certification-vendor material. It is often accurate and it is also selling something, so treat capability claims from that source the way you would treat vendor documentation elsewhere: fine for what the framework says, weaker for whether it works.
Use the citation style your task names and place each reference beside the claim it supports. Measurement terms in this space are used loosely in industry, and defining yours removes any doubt about what you are claiming to improve.
What passes, and what comes back
Competent submissions apply rather than summarise. The recommendation follows from criteria, the practice is described as it would run for this specific team on a specific rhythm, roles are assigned to real people with real conflicts acknowledged, and measures are defined. They read as though someone could start on Monday.
Returns share four signatures. The document explains what scrum is for a page and a half and never touches the scenario. Ceremonies are listed with no purpose attached, which reads as ritual. The recommendation is agile in general rather than a specific approach with specific mechanics. Or the measures section proposes tracking individual output, which contradicts the collaboration principles the same document just endorsed.
A quick check catches the summarising failure. Count how many sentences in your draft mention something from the scenario by name. If the answer is fewer than one in five, you have written an essay about agile rather than an analysis of this team, and the aspects will score it that way.
Nothing is deducted when performance assessment work goes back for revision, so finish every aspect and submit rather than continuing to edit, and let the evaluator find the last gap faster than you would. If your course also carries an objective assessment, note that WGU objective assessments are proctored and our boundary is absolute: preparation only, including framework drills, practice questions and a candid read on your preassessment result. Sitting an assessment for you is not something we do, stay out of the room entirely, and we would refuse portal credentials if they were offered.
Written about agile instead of applying it?
Send the E007 rubric and scenario. We rebuild it as criteria, comparison and a runnable recommendation, with word targets per aspect.
Seven mistakes that cost time in E007
- Summarising the framework. The aspects ask what you would do for this team. Definitions are the setup, not the answer.
- Ceremonies without purpose. Every event exists to answer a question. Name the question or leave the event out.
- Treating scrum as the default. A steady stream of unpredictable requests is a flow problem, and imposing sprints on it can make things worse.
- Roles with no people. Assign each role to someone in the scenario and say what they give up to take it.
- Measuring individuals. Individual output metrics undercut the collaboration the approach depends on, and the contradiction is visible.
- Citing consultancy content for outcomes. Framework guides define practice. Research evidences results. Keep the two sources apart.
- No review point. Agile approaches are meant to be inspected and adapted. Say when you would look again and what would make you change course.
Three questions students ask about E007
Do I need software development experience?
Should I recommend one approach or a blend?
Is ITEC 2201 a separate course from E007?
Where E007 sits in WGU's programs
The July 2026 catalog places this code in 2 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.