TeamAgilityFlowScorecardMASTER
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
 
ABCDEFGHIJKLMNOPQRSTUVWX
1
Note: The term 'coach' is used instead of Scrum Master or Kanban Coach.To learn more about team agility click this box.
2
Team Agility Flow Scorecard MASTERStartCur- RentGoal
3
Team Agility Scorecard <---- Less Flow ... More Flow---->
(scores are examples
4
Roles, Mindsets, Events, Artifacts (links go to more info)Objectives123456789101112131415
Score
Score
Score
5
1Product owner roleHave a clear liason for the team to go to understand what work needs to be done and why.no product owner role is definedDoing about 25% of the roleDoing about 50% of their roleDoing about 75% of their roleDoing virtually all of their role1510Roles0
6
2Team Agility Coach role
(Scrum Master)
Have a coach for the team to assist them in improving their definition of workflow and in following it. They are responsible for liasoning between the team and the rest of the organizationno one is doing this role or it's being done by several people rotating the responsibilityattending to the duties of the team agility coach but mostly just attending to the project management aspects of it.the role is being filled by some who is attempting to manage improvements but is taking a dogmatic attitude towards following a particular framework or methodthe coach is taking respnosibility for the team's workflow and agreements and works with the team to improve themall responsibilities to left plus attending to the bigger picture of how the team fits into realizing value quickly for the oranization15100
7
3Cross-Functional Development teamTeams are cross-functional. That is, they have all of the capabilities needed to create value quickly in a predictable, sustainable and high quality fashion.the development team is scattered and working on other things besides the main focus of what they are intended to dowhile teams aren't co-located they are in simiilar time zones and are focused on the same work being done (some team members may be split across teams)while teams aren't co-located they are in simiilar time zones and are focused on the same work being done (team members also doing work for other teams have kanban boards)the team is cross-functional and is focused, albeit not co-located, on completing the work of the sprint backlogthe team is cross-functional and co-located15100
8
9
4aQuality of sprintsHave work be completed in a timely manner that provides quick feedback and is potentially realizable. (Note, if using cadence must attend to story size objectives more closely as cadence does not provide that guidance)Sprint boundaries are mostly ignored.A sprint consists mostly of one big design, code, and test cyclesStories are mostly completed but many tests are not completed by the end of the sprintMost stories are started at beginning and are done close to the finish of the sprint - all stories have a cycle time approx equal to the sprint time box lengthIf using iterations, all work is completed at the end of a sprint. If using cadence, cycle times of work in cadence interval is less than three days1415
10
4bQuality of cadenceNo cadence is being used.cadences are defined but not consistently used.Cadences for readying work prior to hitting the team, demos, retros are being done1412
11
12
5Estimation, velocityVelocity helps coordination. Inability to estimate points to problems in workflowstories that are almost ready to be worked on or commited to (if using sprints) are large but at least they are estimatedstories have been broken down into smallish size but are not being estimated. this makes it not possible to calculate velocityEstimation is being done consistently whereever it is advisable1510
13
6Focus on Finishing / Managing Work in ProcessKeep work within capacity. Lower cycle timeWork is started in an ad hoc mannerGenerally each person on the team starts work on a separate storywhen starting a task people look to see how that story will contribute to finishing the bigger piece the story is inafter finishing something they look to see how they can help someone else on their team to finish somethingafter finishing something they look to see how they can help someone else on their team finish something that will shorten cycle time of the MBI the team is working on.1510
14
7Sprint PlanningCreate a plan to improve focus and help people see what is happening to enhance dependency managementNot being doneplanning is done but it is mostly guesswork0planning is done base on velocity of the teamSprint planning is being done and all stories on the sprint backlog have met DoR and DoD definition1510
15
8Daily Retrospectives (Daily Scrum)Communication, collaboration, ability to pivot, remove blockagesNot being doneDaily standups are done but are mostly walk throughs without any action coming from them.Daily standups are being done but from an individual perspective:
what did "I" do
what am "I" going to do
where am "I" blocked
Daily standups are being done but from a team perspective. so thet "3 questions" are more "we" than "I". but they are mostly being used to provide status instead of taking action.Standups happen the same time and place and are more about how to work together and solve problems with little status being needed. Blockages that haven't been fixed the day before are always mentioned so as not to just let them become status quo1510
16
9Product DemonstrationGet feedback from stakeholders and product owners and make any necessary corrections on directionNo regular demonstrations are doneInstead of running working software progress is disucssed via presentatino.Software built is demonstrated but not enough attention is given to providing feedback.working software is demonstrated. and feedback given is well received1510
17
10Continuous learning
(Retrospectives)
Use for improving the methods of the teamNot being doneRetrospections are done but are mostly just walking through the steps.Retrospections are done but not followed up onRetrospections take place at end of sprint/cadence and 1 to 2 things are selected and worked on for improvement over the next sprint. Organizational Impediments are made visible and Management removes these.158
18
11Product backlogEnsure backlogs are ready when a sprint or cadence startsThere is no product backlog, but teams are just given work on an adhoc basisthere is a product backlog from which the team pulls but it is not well organizedThe backlog has a couple of weeks of medium to small stories in it.The backlog is refined to the extent that, if sprints are being used, at the next planning event there are enough ready stories for planning. These stories can be traced back to the MBIs from which they sprang and dependencies of and on these stories have been identified.1510
19
12Sprint backlog
20
13Building the IncrementBuild demonstrable software on a regular, frequent basis.at the end of the sprint/cadence there is nothing to demodemonstrable software gets completed at infrequent timesat the end of a sprint/cadence software has been built that is tested and demonstrable but is not integrated with other needed piecesat the end of the sprint/cadence what has been built is fully teested and can be demonstrated to the product ownerContinuous integration and continuous deployment is happening157
21
14Definition of Ready & Definition of DoneEnsure people are working on the right thing and not starting their work until it is ready to be startedThere is no definition of ready or definition of doneDoR and DoD are defined, but not commonly usedDoR and DoD are defined and mostly usedDoR and DoD are well defined and being used for all stories
22
23
24
25
3815
26
-------------
--------------------------
-------------
2815Mindsets5
27
-------------
--------------------------
-------------
28
1Self-organization within the context of the development groupUse for improving the methods of the team while not leading to local optimization that hurts the overall bic picture.Team members are just trying to get their job doneTeam members self-organize but don't attend to the context they are in.Team members work together to improve how they are working while attending to their agreements with the rest of the organization18152
29
2Definition of workflowImprove collaboration within the team and make it easier for people to move from team to team when requiredThere is no definition of workflow besides "on backlog", "in process", "done"The workflow includes some indication of whether stories have had acceptance criteria defined prior to starting workAll of the steps required to do the work have been explicitly discussed and are know by the team. In particular, it is clear what DoR and DoD are and if they are being used38152
30
#REF!Managing impedimentsCreate visibiliy on what's holding the team and/or organization back and work on them on a regular basisImpediments are mostly ignored and just treated as isAn impediment list is created but not used for muchAn impediment list is maintained and worked on on a regular basis. it is reviewed daily.15122
31
1812Artifacts5
32
1Visibility of work (team backlog)Enable other teams to see both what will be required of them as well as when what they are depending upon is being developedWork is not visible. There is no organized list of work to be doneA sprint backlog exists, but the state of the work is not shown other than "in process" and "done"All work regarding the team is visible, including stories added to the sprint after it started for whatever reason, side effect of interruptions, any blockages presentVisibility in the prior column exists as well as any dependences on other groups, dependencies that people have on us including work upon Kaizen activities - continuous improvementsVisibility in the prior column exists as well as work of different types such as customer focused on systems focused58150
33
2StoriesSmaller batches assist flow and predictability. Velocity helps coordinationstories that are almost ready to be worked on or committed to (if using sprints) are large and not estimated)stories that are almost ready to be worked on or commited to (if using sprints) are large but at least they are estimatedstories have been broken down into smallish size but are not being estimated. this makes it not possible to calculate velocityStories have been broken down so they take more than 2-3 days to be completed, stories are estimated in such a way that velocity can and is calculated by the team135
34
#REF!Burndown / Burnup ChartsUse visual controls to:
1) show rate of completion of work-eg burndown charts
2) see if stories are being worked in proper order
3) see time taken for each step (eg CFD)
4) see type of work being done
No reports that show what is being done are avaialble1 of these reports is available2 of these reports are available3 of these reports are available4 of these reports are available34150
35
#REF!Building the IncrementBuild demonstrable software on a regular, frequent basis.at the end of the sprint/cadence there is nothing to demodemonstrable software gets completed at infrequent timesat the end of a sprint/cadence software has been built that is tested and demonstrable but is not integrated with other needed piecesat the end of the sprint/cadence what has been built is fully teested and can be demonstrated to the product ownerContinuous integration and continuous deployment is happening18120
36
16
37
Copyright (c) Net Objectives.
38
39
Things missing
40
This scorecard is still being built. the following are comments we've received about thngs to add. There is a tradeoff between completeness and degree of complicatedness. Comments welcome
41
MBI mindset
42
Objective Based Thinking
43
measure of team flow behaviors (e.g. none - some pairing - true pair programming - business people working hand in hand with tech developers at task level - mob programming
44
measure of individual flow - or a practice that encourages/supports Flow (e.g. https://www.amazon.com/Flow-Psychology-Experience-Perennial-Classics/dp/0061339202)
45
This IS about SW Dev - so lets talk about storage of artifacts (code Repo)
46
Automated Test
47
Depending upon our situation we should be using time-boxing (10a) or a cadence model (10b). Note the objectives of both is the same.
48
DoD ready must include test specs
49
50
MBI mindset
51
Objective Based Thinking
52
measure of team flow behaviors (e.g. none - some pairing - true pair programming - business people working hand in hand with tech developers at task level - mob programming
53
measure of individual flow - or a practice that encourages/supports Flow (e.g. https://www.amazon.com/Flow-Psychology-Experience-Perennial-Classics/dp/0061339202)
54
This IS about SW Dev - so lets talk about storage of artifacts (code Repo)
55
Automated Test5
Loading...
Main menu