{"id":435,"date":"2025-04-01T18:01:12","date_gmt":"2025-04-01T18:01:12","guid":{"rendered":"https:\/\/permutationcity.co.uk\/bp\/?p=435"},"modified":"2025-03-23T11:32:19","modified_gmt":"2025-03-23T11:32:19","slug":"scrum","status":"publish","type":"post","link":"https:\/\/permutationcity.co.uk\/bp\/2025\/04\/01\/scrum\/","title":{"rendered":"Scrum"},"content":{"rendered":"\n<p>I&#8217;ve given a\n<a href=\"https:\/\/permutationcity.co.uk\/bp\/2024\/06\/18\/a-brief-history-of-agile\/\">brief history of Agile<\/a>\nand talked about\n<a href=\"https:\/\/permutationcity.co.uk\/bp\/2024\/07\/16\/the-agile-manifesto\/\">the Agile Manifesto<\/a>,\nthose were both research driven.\nHowever I can talk about\n<a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)\">Scrum<\/a>\nfrom personal experience.\nI&#8217;ve been involved with a couple of more tentative uses with a few Scrum ceremonies but\nalso done it properly with the bells and whistles.\nOverall I enjoyed using it and\nthink it has a lot of positive elements but\nthat doesn&#8217;t mean it&#8217;s perfect.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ceremonies-and-terminology\">Ceremonies and terminology<\/h2>\n\n\n\n<p>I&#8217;d say you need these call it Scrum: <\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)#Sprint\">Sprint<\/a>: Progress through the project is broken up into regular phases.<\/li>\n\n\n\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)#Post-sprint_events\">Retrospectives<\/a>: A meeting where you look back over the previous sprint for successes and failures.<\/li>\n\n\n\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)#Post-sprint_events\">Planning sessions<\/a>: A meeting where you pick what tasks to focus on during the next sprint.<\/li>\n\n\n\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)#Daily_scrum\">Stand-ups<\/a> or daily scrums: A short daily meeting where you share your progress and any problems.<\/li>\n\n\n\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)#Product_backlog\">Product backlog<\/a>: A prioritised list of known tasks and requirements for the product<\/li>\n<\/ul>\n\n\n\n<p>For me almost everything else is optional but\nalthough you can throw something together there are definitely\n<a href=\"https:\/\/www.scrum.org\/\">official approaches<\/a> to Scrum. \nI&#8217;ve even done a course and got a certificate. \nYou learn the ceremonies and the proper names for things. \nIt was interesting to see the by the book approach.\nKnowing what&#8217;s in the book is good but\nI think blindly following it is bad.<\/p>\n\n\n\n<p>You&#8217;ll probably also come across some named roles:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)#Product_owner\">Product owner<\/a>: Who represents the customers or business interests to the developers.<\/li>\n\n\n\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)#Scrum_master\">Scrum master<\/a>: Who is responsible for guiding the Scrum process to make sure things stay on track.<\/li>\n<\/ul>\n\n\n\n<p>Plus some named artefacts:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)#Sprint_backlog\">Sprint backlog<\/a>: A prioritised list of tasks for just this sprint.<\/li>\n\n\n\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)#Burndown_chart\">Burndown chart<\/a>: The progress of tasks during this sprint.<\/li>\n\n\n\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Scrum_(software_development)#Velocity\">Velocity<\/a>: The amount of work a team can generally do in a sprint.<\/li>\n<\/ul>\n\n\n\n<p>There may be different variations but this is what I used.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"regular-meetings\">Regular meetings<\/h2>\n\n\n\n<p>A strong theme in Scrum is regular meetings.\nIt has meetings every day and every sprint, say, every two weeks.\nSome might complain that these events are wasting time that could be better spent on productive tasks.\nI think the crucial thing to realise here is that meetings are meant to be <em>short<\/em>.\nA stand-up shouldn&#8217;t be more than 15 minutes and is probably less.\nRetrospectives and planning sessions take longer, maybe up to a couple of hours together.\nAssuming a 7.5 hour day that&#8217;s 6% on meetings.\nLast time my team tended to have 10 minute stand ups and just an hour at the end of the sprint,\nthat&#8217;s only 3.5%.<\/p>\n\n\n\n<p>I think it might be possible to waste time by picking too short sprint or having overly large teams.\nUsing one week sprints you&#8217;re doubling your overhead.\nSpending 12% on meetings might be worth it&#8230; but maybe not.\nDoubling your team is even worse because of the\n<a href=\"https:\/\/permutationcity.co.uk\/bp\/2024\/03\/01\/interconnection-complexity\/#team-problem\">team problem<\/a>.\nI can imagine that quadrupling your overhead&#8230; that&#8217;s 24%.<\/p>\n\n\n\n<p>I think 5% of the sprint on meetings sounds okay and 25% sounds like too much.\nThat&#8217;s still a bit abstract.\nIf the meetings aren&#8217;t valuable then this is just a waste.\nWhat do you get for your time?<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"stand-ups\">Stand-ups<\/h2>\n\n\n\n<p>These should happen every day at a regular time.\nIt doesn&#8217;t matter too much when they are, morning or afternoon,\nwhenever is the best time to get everyone.\nAll the developers get together and report on progress and problems.\nThere should be enough detail so people can follow along but\nnot so much that it gets bogged down in technicalities.\nIt shouldn&#8217;t be &#8220;The same as yesterday&#8221; or &#8220;Networking stuff&#8221;.\nNor should it be a list of ticket numbers ticked off.\nIt should be a little summary of your day that can be understood,\neven if they&#8217;ve been away for a few days.\nThat might take a minute or two.\nIf it takes five minutes you&#8217;ve probably gone too far.<\/p>\n\n\n\n<p>Beforehand each person only knew about there own progress and problems.\nNow everyone knows, at least a bit, about everyone else&#8217;s.\nAn individual might be stuck but\nsomeone else in the group may have seen this before.\nEven if it&#8217;s not exactly the same it can spark a memory of something similar.\nAs new components are added to the system everyone can hear about them.\nMaybe that&#8217;s just what they need to have as well.<\/p>\n\n\n\n<p>Hearing about your colleagues progress gives more flexibility to the team.\nI&#8217;ve often been asked to provide information or expertise when someone is ill or on holiday.\nAs I already know, roughly, what their situation is I can either provide this immediately or\nget up to speed much more easily.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"retrospectives\">Retrospectives<\/h2>\n\n\n\n<p>I talked about retrospectives as part of my first\n<a href=\"https:\/\/permutationcity.co.uk\/bp\/2024\/04\/02\/retrospective-1-26\/\">blog retrospective<\/a>,\nread that for the full story.\nTypically the questions for everyone are something like &#8220;What did we do well?&#8221; and &#8220;What did we do badly?&#8221;.\nI thought it might be better to have:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>What happened?<\/li>\n\n\n\n<li>Was it good or bad?<\/li>\n\n\n\n<li>What to do about it?<\/li>\n<\/ol>\n\n\n\n<p>The first question is simple because it&#8217;s the same as the daily stand-up.\nThat set us right up the second question:\nare the those things good, bad or somewhere in the middle.\nFinally what should we <em>do<\/em> about all of that.\nGenerally speaking, try to encourage more of the good and less of the bad.\nThat may or may not be possible.\nIf someone has been ill for the entire sprint that&#8217;s bad but\nyou can&#8217;t really control if someone is ill.\nHowever you could try:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensuring that more that one person is qualified to work on a task.<\/li>\n\n\n\n<li>Improve document on the tasks and the project so someone else can get up to speed faster.<\/li>\n\n\n\n<li>Allow more slack in the schedule to account for illness.<\/li>\n<\/ul>\n\n\n\n<p>All of those would reduce the impact of future illness and give more flexibility but, unfortunately,\nslow things down in general.\nYou have to decide which ends up costing more in the long run.\nA fairly typical two week sprint means all tasks are recent,\ndetails are less likely to be forgotten.\nThere&#8217;s a chance to change things rather than continuing with a broken system.<\/p>\n\n\n\n<p>I think the retrospective is mostly like to fail in actually turning ideas into actions.\nDeciding that you should improve documentation is one thing,\nactually improving it is another.\nIt could be that ideas aren&#8217;t translated into tasks or\nit could be that there is no time or priority or inclination to carry out those tasks.\nComing up with ideas can certainly be easier than carrying them out.\nI suggested part of the retrospective process should\n<a href=\"https:\/\/permutationcity.co.uk\/bp\/2024\/04\/02\/retrospective-1-26\/#meta-retrospectives\">look back farther than the last sprint<\/a>\nto monitor this.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"planning\">Planning<\/h2>\n\n\n\n<p>After you reviewed the last sprint it&#8217;s time to plan the next sprint.\nThe team keeps a product backlog which is a prioritised list of tasks.\nGenerally speaking the highest priority tasks are transferred to the sprint backlog to be completed next.<\/p>\n\n\n\n<p>In order to do this the product backlog has to be kept in order.\nThis requires that new tasks are given an appropriate place within the backlog.\nOld tasks may also need to be re-prioritised sometimes as requirements are refined or circumstances change.\nRegular sessions between the product owner and developers should ensure this reflects the needs of both sides.\nTasks may initially be created that are large or vague.\nHowever as they rise up the backlog they must be broken down into smaller tasks and fleshed out.<\/p>\n\n\n\n<p>I would like to experiment with an\n<a href=\"https:\/\/permutationcity.co.uk\/bp\/2024\/02\/02\/how-to-manage-a-backlog\/#outer-and-inner-backlog\">outer and inner backlog<\/a>,\nessentially one backlog for each side.\nThis would remove unnecessary implementation details for the product owner view,\nshowing the big picture.\nMeanwhile the developers can concentrate on that implementation detail and\nhow to best achieve the overall goals.<\/p>\n\n\n\n<p>Tasks are normally estimated using an arbitrary &#8220;points&#8221; system.\nAt the start of the project their is no direct translation between points and time.\nSmall tasks are given small point estimates and large tasks are given large point estimates.\nAfter a while, when more tasks have been completed, the average relationship between points and\ntime for this team and project will appear.\nThe average number points completed over the last few sprints may be calculated and known as the &#8220;velocity&#8221;.\nThis can be a good way to control how many tasks should be scheduled for each sprint.\nDon&#8217;t expect velocity to be exactly the same from sprint to sprint and\ndo remember to account for holidays and similar things.<\/p>\n\n\n\n<p>Some people take the sprint backlog as a set of work that should be guaranteed to be completed in the sprint.\nI don&#8217;t think this makes sense.\nIf you <strong>have<\/strong> to complete all of these tasks then the likely response is to pick fewer tasks,\neven if you can <strong>probably<\/strong> do more.\nI would take these tasks as a goal,\nideally you&#8217;ll complete or make substantial progress on them.\nHowever if you&#8217;re normally left with a lot of unfinished tasks at the end of your sprint\nyou are probably picking too many.<\/p>\n\n\n\n<p>As much as possible tasks should be designed such that they can be completed within one or,\nperhaps, two sprints.\nIf tasks are regularly overrunning then splitting them up is desirable.\nSometimes they can be broken down into sensible parts.\nThis could include things like investigations, prototypes, implementations, documentation phases.\nIf not then breaking them into a number of arbitrary phases may help.\nThe overall task may not be finished but at least everyone can see that phases have been finished.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"in-the-end\">In the end<\/h2>\n\n\n\n<p>I&#8217;ve certainly given Scrum a better write up than the Agile Manifesto.\nI think the structure of Scrum helps drive communication and gives concrete direction.\nIn contrast the Agile Manifesto is exceedingly loose.\nIt might work, it might not.\nIt very much depends on the specifics that actually get used.\nI feel individuals are\n<a href=\"https:\/\/permutationcity.co.uk\/bp\/2024\/01\/31\/we-all-make-mistakes\/\">too liable to error<\/a>\nto rely on it all just working.\nOn the other hand a strict set of rules from an official Scrum manual might not be what your team needs.\nIn the end these system provides tools and you need to pick the right tools for your job.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I&#8217;ve given a brief history of Agile and talked about the Agile Manifesto, those were both research driven. However I can talk about Scrum from personal experience. I&#8217;ve been involved with a couple of more tentative uses with a few Scrum ceremonies but also done it properly with the bells and whistles. Overall I enjoyed [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_import_markdown_pro_load_document_selector":0,"_import_markdown_pro_submit_text_textarea":"","footnotes":""},"categories":[1],"tags":[41,11],"class_list":["post-435","post","type-post","status-publish","format-standard","hentry","category-general","tag-methodology","tag-planning"],"_links":{"self":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/435","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/comments?post=435"}],"version-history":[{"count":1,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/435\/revisions"}],"predecessor-version":[{"id":436,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/435\/revisions\/436"}],"wp:attachment":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/media?parent=435"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/categories?post=435"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/tags?post=435"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}