I work in an IT company working with a CMS platform, Sitecore. I am a PM on a 'Managed Service' project. We treat this project as an agile team. We run on a two-week sprint cycle, including Backlog grooming meetings, Sprint planning meetings, Demo's and scrum every day.
We struggle because we are very limited with our hours. We are allocated 100/month, and have 5 team members (myself = PM, Account manager, Lead Dev, Developer, and QA). I am trying to create a Innovation deck to propose some ideas to the client of ways we can utilize the hours best. A few of these ideas are:
- Stay on the two week sprint cycle
- Move to a Month sprint cycle
- Have smaller sprints on average, then one large sprint (every once in a while)
- Move to Kanban
If anyone has any other Ideas I wold love to hear them! Saving Changes...
Back in the waterfall days I never scheduled anyone at 100%.....80% max. Sounds like you are doing a lot of the right things. How many hours left for pure development after all those other daily activities Saving Changes...
If I understand correctly, allocation 100/month means you are doing other work too. This means that you are experiencing multitasking, which should not be in a Scrum/sprint environment. Multitasking is bad for efficiency.
One idea would be either skip/downprioritize the other work or try to do 2-week sprints 100% and try to do the other work in the other 2 weeks. (or even go down to 1 week, alternating.
Do not think that sprint durations alone bring much benefit.
Kanban could be another option, but really does not much against incoming requests for other work. Saving Changes...
When faced with such constraints, you will want to lean out your processes, including the governance ones. For example, if doing testing and deployments has been very manual, you will want to streamline that as much as possible with CI/CD, defect prevention practices (e.g. TDD, pair programming) and leveraging test automation.
The problem is you are thinking about time. You have to define your sprint duration (you did that, two weeks) and you have to define what to do inside the sprint without thinking about hours or something like that mainly distributing between roles. Into each sprint you have to do what you have to do to achieve the sprint goals. No more than that. Saving Changes...
Stephanie, it is pretty obvious (to me) that you use the wrong approach. You have 3 people that don't deliver anything (not debating that they don't contribute) a too short sprint for a tam that never implemented Scrum and a very unrealistic expectation that you can be 100% allocated in an Agile project.
Sitecore is a pretty old technology and I doubt that you can implement CI/CD and TDD.
My recommendation, knowing Sitecore, is to start using a planned approach. Your team is not very Agile. 5 People 5 Roles is not agile. I also debate the value of the QA, which I assume that is in fact QC or tester. A CMS doesn't require that much testing, because it's easy to change using the tools that you have.
Kanban won't help either, because all it can do it's to visualise that you have too much to do and not enough resources.
One solution is to replace the "QA" with a developer or let him create sites/pages rather than the developers. If the 2 developers (do you really need a lead developer for a team of 2) are doing customisation on Sitecore then you need to allow more than 30% contingency for unknown.
Longer sprints help always in teams without experience with Scrum but you should first ask what's the benefit of Scrum, without a Scrum Master.
You may be better using a planned approach, setting up incremental delivery and planning each release. Once your team sets up the scope for a release you can work with the Account Manager on planning the next release. That will free the developers and let them be more productive. Hard to see the benefit of the "QA" in a small team. QA is normally the responsibility of the Project Manager. QA doesn't mean testing and if you really had a QA in your team then you wouldn't use Scrum.
My recommendation is to read the Scrum Guide and see if you can apply the framework. In Scrum there are 3 roles PO, Developer and SM and it is recommended a team of 7-9 developers. You have basically 3 POs and and 2 developers.
I would assume that tasks are assigned to the developers rather than them picking what they should do in every sprint based on a prioritised backlog. Saving Changes...
Agree with Sergio. You need to think in terms of deliverables and not time. I have to ask the question though - what is the driver of behind the question? Are you trying to deliver ALL the requirements within a specified budget, timeframe, and resource constraints? With Agile the idea is not to deliver all requirements at all cost, it's about delivering a workable product. If during your grooming it was determined that ALL the requirements are needed to deliver a workable product then you either need to redefine workable product or pull out a magic wand.
I'll make the assumption that your team is your team and you do not have the luxury of changing the team and that you are utilizing the time for standups and reviews effectively and not discussing last nights Netflix ;) Saving Changes...