MT247 · Unit 5

MT247 Unit 5 estimation exercise example

Agile and Scrum Methodologies Purdue University Global Free custom sample in 24 to 48h

When the development manager asked how many hours a story point is worth, Larkspur Residential's Developers declined to answer, and the MT247 Unit 5 estimation exercise explains why through a planning poker session on nine backlog items, the discussions that closed a spread of three to thirteen points, and a forecast given as a range of Sprints instead of a date.

What this page holds

In MT247 Unit 5, the Developers size ten items at forty-nine points by planning poker against a two-point reference story, then forecast a range of Sprints they own. Searches like "mt 247 unit 5 assignment example", "mt247 unit 5 sample" and "mt247 unit 5 example" land here.

What a finished MT247 Unit 5 estimation exercise looks like

A method note heads the five pages: relative estimation in story points on the scale 1, 2, 3, 5, 8, 13 and 20, anchored to a reference item, a resident canceling an open request, sized at 2. The session record follows as a table: item, each Developer's first card, the discussion in a line, and the final estimate. Four of nine items converged in the first round. The photo attachment item opened at 3 to 13 and settled at 8 once image compression came up; permission-to-enter windows opened at 2 to 8 until the Product Owner confirmed the first version only records the window; Spanish-language screens opened at 5 to 20 and were split into 8 and 5. The estimates total 49 points. A forecast section closes the exercise, using recent velocities of 19, 24, 17 and 22.

How a MT247 Unit 5 example is structured

Relative sizing needs a fixed point, so the reference item is chosen first and every later card is a comparison with it rather than a guess in hours. First cards are recorded before any discussion because the spread is the useful information: a 3 beside a 13 means two people imagine different work. Each wide spread is closed by a fact, not by averaging, and the fact is written into the table so the Product Owner can see what the estimate assumed. An item still too uncertain after discussion is split rather than forced into a number. The forecast section divides the 49 points by the highest and lowest recent velocities, giving two to three Sprints, and says the range is the Developers' forecast, not a commitment. The paper closes on the hours question: converting points into hours would turn a team's relative judgment into someone else's deadline.

A two-point anchor

Canceling an open request is small, well understood and already built, which makes it a stable reference that every later card is compared against.

First cards kept on record

Each Developer's opening card is written down before anyone speaks, because a spread from 3 to 13 shows the team imagining different work.

Spreads closed by facts

Image compression settled the photo item at 8, and a Product Owner's clarification about recording rather than unlocking brought permission-to-enter windows down to 3.

An item split, not forced

Spanish-language screens opened at 5 to 20 and became two items, request flow screens at 8 and notifications and emails at 5.

Two to three Sprints

Forty-nine points against recent velocities between 17 and 24 give a range, stated as the Developers' forecast and not as a promise to anyone.

Why points stay points

The manager's hours question is answered directly: converting relative sizes into hours would hand the team's judgment to someone building a deadline.

Where marks go in MT247 Unit 5

Estimates produced by a manager or the Product Owner and handed to the team contradict the ownership this unit tests, and graders commonly check who supplied every number. Story points converted into hours, or velocity treated as a productivity score, repeat the misuse the course warns against. Averaging a wide spread instead of discussing it discards the most useful signal in the session. A forecast stated as a single date, rather than a range drawn from observed velocity, overstates certainty. Papers presenting story points as a requirement of the Scrum Guide get a basic fact wrong, since relative estimation is a complementary practice. A missing reference item leaves the scale floating. Items too large to estimate that are forced into a number instead of split, and velocity figures with no source, account for the lesser losses.

Get a MT247 Unit 5 example written to your instructions

For estimates a team would own, the sample needs the backlog items or case your Unit 5 prompt provides, any velocity history and the rubric. It arrives inside 24-48h and costs nothing the first time, with a reference item fixed, every spread discussed and the forecast given as a range of Sprints.

MT247 Unit 5 questions, answered

Are story points part of Scrum?

No. The 2020 Scrum Guide says the Developers who will do the work are responsible for sizing, but it prescribes no technique. Story points and planning poker are widely used complements. The example presents them that way in its method note, which keeps the paper accurate while still using the practice most sections expect to see in this unit.

Why not just average the cards?

Because the spread carries information an average destroys. A 3 and a 13 on the same item usually mean two Developers picture different work, one of them seeing something the other missed. The example discusses each wide spread until a fact closes it, such as image compression, and writes that fact beside the estimate so the assumption stays visible.

Can velocity be used to compare two teams?

Not meaningfully. Each team's points are anchored to its own reference items, so one team's eight has no fixed relation to another's. Velocity helps a single team forecast its own work, as the example does with a range of Sprints. Used to rank teams or measure productivity, it tends to inflate, which the course usually takes up around this point in the term.