Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
Image
Scrum rests on empiricism: transparency enables inspection, and inspection enables adaptation. Most Scrum Teams I work with are reasonably good at inspection and adaptation. Where they struggle is the first one.Transparency is not the same as having a tool. A board shows where every item sits right now, and it shows that well. But a Sprint Retrospective rarely turns on where work is - it turns on where work waited, and for how long, and whether that pattern is changing. That information exists in your tooling. It is almost never on the screen.This article walks through three short Python scripts that surface it. All three are read-only. None of them makes a decision, updates an item, or replaces a conversation. They exist to give the Scrum Team something concrete to inspect.Before anyone asks: no, Scrum Masters do not need to learn Python. I will come back to that at the end.The transparency gapConsider three questions a Scrum Team might reasonably want to answer.Of the work we completed recently, how long did each item spend in each state? The board shows current state only. The history is in the API, not the interface.Is our capacity to confirm work is correct keeping pace with our capacity to produce it? This spans two systems - the work management tool and the code repository, and no single view joins them.What changed over the last quarter? This needs a trend, and most reporting shows a snapshot.None of these is exotic. All three are invisible by default.It is worth saying plainly that Scrum prescribes none of this. The Scrum Guide does not define a board, a column, or a metric. What it does ask for is transparency sufficient to inspect, and it leaves the means to the Scrum Team. Scrum.org's Evidence-Based Management guidance goes further on what is worth measuring; this article is narrower, and is only about making existing data visible.Script one: how long work waits in each stateMost work management tools record every state transition with a timestamp. Pull the recently completed items, reconstruct the transitions, and you get the median time each item spent in each state.Here is the result from one team's last sixty completed items:
Image
Read the shape rather than the numbers. This team is not slow at building. It is slow at confirming that what was built is correct. Roughly four-fifths of an item's life is spent after the code exists, waiting for a person to look at it.There is a second observation sitting in that output, and it is the more uncomfortable one. A column called "Ready for QA" holding items for a median of fifty-four hours suggests that testing is not genuinely inside the Definition of Done, it is a downstream stage the Increment passes through afterwards. That is a Definition of Done conversation, and it is not one this team was having.import requests, pandas as pd
from datetime import datetimeAUTH = (EMAIL, API_TOKEN)
JQL = 'project = ABC AND statusCategory = Done ORDER BY resolved DESC'r = requests.get(
f"{BASE_URL}/rest/api/3/search",
params={"jql": JQL, "maxResults": 60, "expand": "changelog"},
auth=AUTH,
)rows = []
for issue in r.json()["issues"]:
# The changelog records transitions only, so the opening state has no
# start event. Seed it from the item's creation timestamp.
created = datetime.fromisoformat(issue["fields"]["created"][:19])
events = [(created, "To Do")] + sorted(
(datetime.fromisoformat(h["created"][:19]), item["toString"])
for h in issue["changelog"]["histories"]
for item in h["items"] if item["field"] == "status"
)
for (t1, status), (t2, _) in zip(events, events[1:]):
rows.append({"key": issue["key"], "status": status,
"hours": (t2 - t1).total_seconds() / 3600})df = pd.DataFrame(rows)
df = df[df.status != "Done"] # Done is terminal, not a queue
print(df.groupby("status")["hours"].median().sort_values(ascending=False).round(1)) Note what the script does not do. It does not tell you why. Reviewers may be overloaded, items may be too large, testing may sit with a separate group. Diagnosing that is the work of the Sprint Retrospective. The script only ensures the conversation starts from evidence rather than from whoever speaks first.Script two: where the constraint movedThis is the one I think matters most at the moment.When Developers adopt AI coding assistants, producing code becomes faster. Confirming that code is correct does not. The constraint relocates, and throughput measures do not notice, because they count completed items rather than where items queue.Three numbers from the same team's pull request history make the shift visible:
Image
The gap between the fiftieth and ninetieth percentile is the finding. Half of all pull requests get a first look inside a day. One in ten waits more than three days. Median change size over the same quarter grew from roughly 140 lines to 410, which is what you would expect when generating code becomes cheap, and which explains the latency, because nobody opens a four-hundred-line change at the end of the day.import requests, pandas as pd
from datetime import datetimeHEADERS = {"Authorization": f"Bearer {GITHUB_TOKEN}"}
REPO = "your-org/your-repo"prs = requests.get(
f"https://api.github.com/repos/{REPO}/pulls",
params={"state": "closed", "per_page": 100},
headers=HEADERS,
).json()rows = []
for pr in prs:
if not pr["merged_at"]:
continue
reviews = requests.get(pr["url"] + "/reviews", headers=HEADERS).json()
opened = datetime.fromisoformat(pr["created_at"][:19])
merged = datetime.fromisoformat(pr["merged_at"][:19])
first = min((datetime.fromisoformat(rv["submitted_at"][:19])
for rv in reviews if rv.get("submitted_at")), default=None)
rows.append({
"pr": pr["number"],
"hrs_to_review": (first - opened).total_seconds()/3600 if first else None,
"hrs_to_merge": (merged - opened).total_seconds()/3600,
"size": pr["additions"],
})df = pd.DataFrame(rows)
print(df.describe(percentiles=[.5, .9])) What follows from this is a working agreement discussion, which sits squarely within the Scrum Master's accountability for the Scrum Team's effectiveness. Do the Developers cap change size? Reserve a review-first hour? Pair on generated code rather than reviewing it asynchronously? Those are the team's decisions. The data only establishes that there is something to decide.One caution worth stating. If completed-item counts are rising while review latency also rises, the delivery system is accumulating a queue, not accelerating. Treating the first number as improvement while ignoring the second is how teams commit to a forecast they cannot meet.Script three: opening the Sprint Retrospective with observationsMany Sprint Retrospectives open cold, and the agenda gets set by whoever is most confident. Arriving with three or four observations changes the first ten minutes.Observations, not conclusions. You put them up and ask whether any of it matches what people experienced. Sometimes the answer is no, and that is a useful answer. signals = []reopened = df[df.status_sequence.apply(lambda s: "Done" in s and s[-1] != "Done")]
if len(reopened):
signals.append(f"{len(reopened)} items returned after being marked Done")slow = pr_df[pr_df.hrs_to_review > pr_df.hrs_to_merge * 0.6]
if len(slow):
signals.append(f"{len(slow)} changes spent over 60% of their life awaiting first review")print("\n".join(f"- {s}" for s in signals)) These are deliberately simple threshold checks. No model, no clustering, no sentiment analysis, and that simplicity is the point, which brings me to the line I will not cross.The line I will not crossDo not put team members' words through a model without their explicit knowledge and agreement. Not Sprint Retrospective comments, not chat messages, not survey free-text.The Sprint Retrospective works because people say the true thing. The moment anyone suspects their words are being processed, summarised, and possibly forwarded, they stop saying the true thing, and you have traded a working inspection for a tidy-looking summary. That trade is very difficult to reverse, because trust does not return on the schedule you would like.So: instrument the system data. Items, commits, timestamps, pipelines. Leave the human data alone unless the team has consented and controls what happens to the output.Three things I would not automateWriting to the work management tool. Automatic transitions and bulk updates are mostly a native automation rule anyway, so scripting it reinvents a dropdown. More importantly, when the board updates itself it stops being a shared artifact the team maintains together. The friction of a person moving an item is sometimes doing real work.Automated stakeholder reports. A stakeholder trusts your report because you looked at it. Generate the data automatically; write the interpretation yourself.Anything that replaces a conversation. If the output means a discussion does not happen, that is avoidance dressed as efficiency. Each script here is designed to start one.Trying this without production accessYou do not need credentials to see whether this is useful. Both scripts run against a small generator that produces synthetic data shaped like real API responses, with a fixed random seed so results are reproducible. Only the line that fetches the data changes; the analysis is identical.That also makes it a safer way to show a security team what you intend to do before requesting any access at all. Everything described here needs read permissions only. If someone tells you flow analysis requires write scope on a production instance, they are describing automation, not measurement.So do Scrum Masters need to learn Python?No.You can be excellent in this accountability without writing a line of code, and I would be wary of anyone who tells you otherwise. The accountability has not changed: the Scrum Master is accountable for the Scrum Team's effectiveness, and no script does that for anyone.What changes is narrower. If you want to inspect flow with evidence rather than impression, and your tooling does not expose the data, this is roughly two weekends of learning — requests, pandas, and the patience to read an API document once. Not a career pivot. A tool, useful in one specific situation.The value was never the Python. It was walking into the Sprint Retrospective already knowing where the time went, so the hour could be spent on what to do about it. BTW if you are interested in adding the AI essential skills to your kit then join our upcoming online training workshops -AI Training for Scrum MastersAI Training for Product Owners
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Scrum Isn't for Stormtroopers | 0 | 15.26 | 28-07-2026 |
| 2 | You Can Ignore the Flow Data. It Still Decides When You Ship. | 0 | 13.6 | 12-07-2026 |
| 3 | The Project Manager Isn't Dead. It Was Disassembled on Purpose! | 0 | 16.43 | 27-07-2026 |
| 4 | Wie drei Jira-Spalten Release-Prognosen sabotieren – und wie Scrum Teams ihr Board reparieren | 0 | 11.71 | 28-07-2026 |
| 5 | O que aprendeste hoje? | 0 | 10.98 | 14-07-2026 |
| 6 | Cognitive Trap: Velocity Misinterpretation | 0 | 7.37 | 20-07-2026 |
| 7 | AI Interview Agent for Scrum Master and Product Owner Readiness | 0 | 8.4 | 21-07-2026 |
| 8 | Beyond Blame: Transforming Team Dynamics Through Feedback | 0 | 16.56 | 22-07-2026 |
| 9 | Scrum Kumbaya | 0 | 16.01 | 13-07-2026 |
| 10 | Der heimliche Feind jedes Product-Owners: 5 Mythen, die Karrieren ruinieren | 0 | 15.23 | 27-07-2026 |